Published on: 2014-02-21T06:30:25+00:00
The email conversations on February 20th, 2014, revolve around the support for P2SH in bitcoinj, the request for BIP numbers, the proposal to implement transaction.version=3, and the discussion on transaction malleability and potential solutions. The conversations highlight the competitive nature of the wallet market and the need for wallets to pick up features at different times. There is a consensus on proceeding with Pieter Wuille's plan to implement version 3 transactions, although it may take years for wallets to start generating them. The proposed solutions aim to address transaction malleability and provide non-malleability guarantees for clients while allowing for certain use cases of malleable transactions. The discussions also touch upon the implications of introducing new rules and versions and the potential risks and forks associated with them.One of the main concerns in the Bitcoin community is transaction malleability, which allows a third party to change the unique ID of a transaction. This issue has been a concern for some time, and various solutions have been proposed. One solution is to make version 1 transactions unmalleable and introduce a version 3 that supports malleability features. However, this would require updating all signers to be anti-malleability compatible, which could be challenging. Another proposed solution is to modify signatures to include the entire transaction, but this was deemed unnecessary and ineffective. Instead, it was suggested that the next Bitcoin version could "prettify" all relayed transactions as deterministic transactions, effectively blocking any malleability attack. There are also discussions about using static IDs or canonical transaction hash/ID (cTxID) to eliminate transaction malleability. Armory, a Bitcoin wallet software, already uses a similar approach and has not experienced malleability issues. However, there are concerns about potential security implications if consensus depends on data not hashed in the Merkle structure of a block. The proposed rules to eliminate transaction malleability are not expected to be controversial, but they may require modifications to wallet software and potentially invalidate some script functionality. It was suggested to make CHECKMULTISIG require the dummy value to be exactly equal to OP_FALSE, but concerns were raised about assuming malleability without solid knowledge of ECC signatures. Instead, it was proposed to add a new CHECKSIG mode for cases where malleability must be eliminated and focus on fixing wallet software.Pieter Wuille's proposal aims to eliminate transaction malleability over time by introducing new rules and potentially changing how transactions are handled in Bitcoin software. The proposal is open to feedback from the Bitcoin community.
Updated on: 2023-08-01T07:38:17.974319+00:00