Achievement unlocked: BCH fixes all common third-party transaction malleability vectors

One of the most recent upgrades to BCH was a fix—enforcing MINIMALDATA in scripts.

According to the previous upgrade specifications, we also clearly understand that this change is to eliminate the final BIP 62 ductility vector, making most transactions (including all P2PKH transactions) on the Bitcoin Cash network after the upgrade impossible Verified, can effectively protect the security of transactions.

So what exactly is transaction malleability? What has BCH done to fix it?

What is transaction malleability?

Transaction malleability (transacTIon malleability) stems from a bug in the Bitcoin source code. This error can change the transaction ID without changing the transaction output or transaction content. This error means that the transaction signature can be changed before the transaction is written to the block by the miner.

In other words, after a transaction is broadcasted, some prank miners can use another signature method to replace the original signature method of the transaction before getting confirmation. Since the TXID of the transaction is obtained by hashing the transaction content, if the signature method inside changes, the TXID will also change.

If it is subjected to a transaction malleability attack, although the funds of the transaction will not be affected in any way, and who should be transferred to whom, those applications that rely on TXID, such as exchanges, will suffer serious losses. Because they will record the TXID of each transaction, if the TXID changes, it will easily lead to chaos in the account, which is why the exchange requires at least one confirmation to enter the account.

In 2014, someone exploited this vulnerability to attack the Bitcoin network on a large scale. The memory pool was full of fake transactions, causing the Bitcoin network to be blocked, causing some full nodes to go down, and the Bitcoin network being extremely unstable. Part of the reason for the closure of the once largest Bitcoin exchange, Mt.Gox, was due to a scalability attack.

What does BCH do to fix transaction malleability?

BCH has upgraded all common third-party transaction malleability vectors through upgrades, while Bitcoin Core has remained.

1. Canonical coded ECDSA signature: Since BIP 66 was activated in July 2015, non-DER coded ECDSA signatures are prohibited.

2.Non-push operations in scriptSig: In the November 2018 Bitcoin Cash network upgrade, non-push operations in signed scripts were banned, and Bitcoin core still accepted them.

3. Push operations in non-standard size scriptSig: In the November 2019 Bitcoin Cash network upgrade, non-standard size push operations in any script are prohibited, and Bitcoin core still accepts them.

4.Zero-filled digital push: In the November 2019 Bitcoin Cash network upgrade, it is prohibited to process numbers encoded in non-standard forms, and Bitcoin core still accepts this.

5. ECDSA signature inherent scalability: Since the Bitcoin Cash network upgrade in November 2017, the use of high S values ​​in ECDSA signatures is prohibited, and Bitcoin core still accepts this.

6. Scalability of signature failure: Since the Bitcoin Cash network upgrade in November 2017, it is forbidden to pass invalid signatures other than null to the OP_CHECK (MULTI) SIG. Bitcoin Core continues to execute the script.

7. Excessive scriptSig operation: Since the Bitcoin Cash network upgrade in November 2018, script execution must produce a clean stack. Bitcoin Core doesn't need this. The Bitcoin Cash network upgrade in May 2019 only added exemptions to specific SegWit-like signature scripts.

8. The input ignored by the script: Since the Bitcoin Cash network upgrade in November 2019, the second input of OP_CHECKMULTISIG (VERIFY) is no longer ignored. In contrast, since Bitcoin Core activated BIP 147 in August 2017, this input must be blank.

What does repairing transaction malleability mean for BCH?

1. Make it possible for the exchange to accept 0 confirmation deposits

In view of the impact of transaction malleability attacks, it is difficult for exchanges to make zero confirmation deposits for security reasons. Once BCH fixes the scalability, then the exchange can consider accepting 0 confirmation deposits, which will also help improve the user experience.

2. Make double spend verification more meaningful.

In order to solve the double spend problem, BCH developers have developed a double spend proof double spend detection tool. If you want to use this tool, you must first repair the ductility, otherwise this tool is meaningless.

BCH has two types of double-spend attacks. One is a double-spend attack that requires a large amount of computing power. The cost is very high and it is impossible to use it for double-spend small transactions. There is also a fast double spend: For example, a merchant selling digital goods supports BCH payment. He accepts 0 confirmation payment. As long as it shows that BCH is received, it will be automatically shipped immediately. At this time, the attacker can try a fast double-spend attack. He first transfers a BCH to the merchant, here called TX1; then at the same time transfers this funds to another address of his own, here called TX2, TX2 will be propagated to other nodes across the network at a faster rate through the tool , Especially getting miners to receive first. When the merchant's system shows TX1, he will think that the account has been received, so he will automatically ship it, but the miner has packed TX2. In the end, TX1 will be invalidated, and the merchant will lose money and the attack will succeed.

The double-spend detection tool is used to specifically detect fast double-spend attacks. This tool will monitor the BCH nodes on the entire network. If a double spend transaction is found, it will issue a warning to remind the payee. If the payee finds a double spend, it can reject the transaction or require a confirmation.

When a double-spend detection tool is added to a mainstream wallet, users can intuitively see whether a transaction has been double-spended, which will greatly increase the user's confidence in the 0 confirmation transaction, and for the exchange, because of this, With the existence of the tool, the risk of accepting a zero confirmation recharge is greatly reduced.

At present, BCH has repaired all common third-party transaction malleability vectors, which greatly solves the problem of malleability attacks. This also creates more possibilities for the future development of BCH, without being restricted by the problem of scalability.