Malleability is an integral part of the Bitcoin network design, thanks to it’s belonging to the Elliptic Curve Digital Signature Algorithm (ECDSA) school of cryptography, whose digital signatures are known to be susceptible.
What this means is that even if the signatures are open to modification by a third party they still will remain valid. The same is also true for other types of digital signatures. For instance, an ECDSA signature which is an (a, b) pair can be malleated as (a, -b). All it takes is changing the secondary function to negative and the validity remains.
Even with SegWit upgrade in place, malleability is only prevented in Segwit transactions, which currently make up for about 5–10% of the total transactions.
This makes malleability a native and inherent ‘feature’ of Bitcoin. But, it also qualifies to be called a bug since it paves the way for some non-desirable consequences. Clearly, this is a gnawing issue which requires immediate and effective addressing.
It is a known fact that transactions not confirmed by miners on the blockchain are not included in a block. They are said to be unconfirmed, pending, “out there in the mempool”, zero confirmation, or “0-conf”. Having at least 1 confirmation is more secure than having no confirmation at all.
0-Conf: Bitcoin Core Vs Bitcoin Cash
According to Bitcoin Core developers, there should be a layered system with high fees on the base layer. Unless a higher fee is levied, the time to confirm an unconfirmed transaction might get extended, or it may never get confirmed at all.
During this time, it could be double spent or replaced with “RBF” (replace by fee). In this system, 0-conf is fairly unsafe and unreliable, which makes sense if Bitcoin Core wants to implement second layer solutions.
The ‘Bitcoin Cash’ philosophy maintains that fees should not be inflated, and blocks should not be full. This makes 0-conf fairly safe and reliable, which makes sense if Bitcoin Cash allows transactions to be conducted on the blockchain.
The Bitcoin Core team wants malleability to be fixed because it helps make second layer services easier to code. It is not even necessary for those services. It just makes some current implementations easier. But that is not a good reason to change the protocol.
A Different Approach
Let’s assume a scenario, in which the block and transaction structure is modified so that the signatures are not a part of the transaction hash.
This is the approach taken by Segwit, Flex Trans, and MalFix.
Satoshi Nakamoto in section 2 of his Bitcoin Whitepaper says, “We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.”
All of these malleability fixes – Segwit, Flex Trans, and MalFix change the aforementioned idea. According to these fixes, a hash of the previous transaction is not signed anymore. Only the transaction without a signature is signed and then included somewhere else in the block.
Segwit is an innovative take at fixing the issue, but it only fixes malleability for SegWit transactions, which currently account for only 5–10% of the total transactions.
Flextrans is a much better proposal. It is a hard fork that only changes a few lines of code. Transactions are not discarded as with SegWit, with malleability being fixed for all transactions.
Hashing the entire transaction before chaining it to the subsequent transaction is not a part of FlexTrans’ game plan. Instead, the signatures still remain in the block and then become part of the entire block’s hash. That hash is then used by the next block
In Bitcoin, a signature must always be present to transfer ownership. The difference with Flextrans is that the security is moved from the transaction level to the block level.
In general, we should extremely careful to change the formula, especially with something as sensitive at how we handle the signatures. But, the important question worth asking here is that If a signature is separate from a transaction, does that make it easier to perform certain kinds of hashing collision attacks?
The answer is not known, but proposals like Flextrans should be deeply studied and peer-reviewed before they are considered for deployment.
The cost/benefit should be evaluated carefully. Especially, the costs involved in deeply researching and analyzing the risks of changing Bitcoin, and the associated benefits.
Our Social Networks: Facebook Instagram Pinterest Reddit Telegram Twitter Youtube
