Legacy transactions can be exploited by increasing processing power

The big “cleaning” of the consensus algorithm (rules) is a soft fork proposed by Matt Corallo. Unlike other protocol enhancements, including those outlined in the previous article, this soft fork is not meant to bring new options or possibilities for the Bitcoin application but rather to remove some vulnerabilities of the protocol.

These are a little more technical and a little more hidden in the code. As examples: the algorithm for adjusting the difficulty, the way in which an upgrade is made in the code and even the modification of the transactions that require a high processing power to be processed. These vulnerabilities are supposed to exist but their exploitation would cost a great deal as much as they can gain from them, so they are considered unprofitable. We can also say that when someone exploits these vulnerabilities, the act of removing the attacker and changing the rules can be very easy.

“The Great Consensus Cleanup”

However, removing these vulnerabilities can make the code more secure and the code easier to do.

The main reason that the “The Great Consensus Cleanup” soft fork was not implemented is probably because this upgrade will make certain currencies (UTXOs) incapable of being spent. It is very unlikely that these coins exist but at the same time it is impossible to identify if there is. Implementing the upgrade can cause unwanted events by certain network participants (those with UTXOs of this type), being at odds with the “Constitution” of bitcoin.

Matt Corallo proposed the fork, emphasizing the main goals, which are relatively unknown to everyday users as well as legacy transactions, but important to those building in the Bitcoin ecosystem.

Preventing users from using P_CODESEPARATOR and FindAndDelete () in legacy (non-segwit) transactions.

We still do not know if users use these two options in legacy transactions, but an attacker can use them, increasing the amount of processing power needed to verify such a transaction. Given that such transactions require high processing power, once included in blocks, their verification time (no: blocks) can take up to 30 minutes longer. Many have not heard about these types of transactions and how to generate such a transaction simply because they can be done very easily using other methods. Anyone who needs OP_CODESEPARATOR can use BIP143 segwit implementation, which eliminates the need for very high processing power.

As a curiosity, these types of transactions were not formatted or networked in the June 2018 Bitcoin Core 0.16.1 release.

Time Warp type attack

This type of attack allows miners who have the majority of processing power (Hash Rate) to manipulate the difficulty (maintain or modify it) even when the processing power in the network increases, allowing them to produce blocks faster than the protocol allows them. The acceleration of the network could allow the miners to mine many blocks (and acquire the block reward for each block found) by circulating all the coins in about 3 weeks from the launch of the attack. Although it seems a very serious problem, the preparation of the attack takes about 7-10 days, during which the network participants observe and can take measures. No one has tried this before and anyway it would require joining several pools with high processing power.

Prohibit the use of non-push opcodes in scriptSig

Due to the fact that Bitcoin, from a technical point of view, still accepts non-push opcodes in scriptSig, an attacker can increase the amount of power needed to verify a transaction included in a block.

Prohibiting the use of non-push opcodes in scriptSig is a policy adopted by miners since 2011 and is prohibited by code for payments to BIP16 P2SH and BIP141 Segwit. The proposed soft-fork introduces changes in the code for all types of addresses.

Prohibiting transactions smaller or equal to 64 bytes.

Since there is no possibility to spend bitcoin securely through transactions smaller than or equal to 64 bytes, the proposed soft-fork prohibits the inclusion of these transactions in valid blocks.
Such transactions can be confused with Merkle Tree hashes or vice versa. This confusion can create vulnerabilities in demonstrating the authenticity of Merkle Tree or SPVs.

All the concepts are explained by Corallo at large and will be tested and evaluated by the experts and by those who hold the keys of the implementation in the protocol, to be subjected to the community adoption test.

More technical details can be found on github.

In the following articles we will talk about:

NoInput Class (NIC) Upgrade
Implementing OP_CHECKTEMPLATEVERIFY
DriveChains and their BIPs (BIP – Bitcoin Implementation Protocol)