Published on: 2016-11-21T21:29:21+00:00
In response to an email from Russell, Tom Zander from the bitcoin-dev mailing list expressed gratitude for his review but mentioned that the issue raised had already been resolved some time ago. It was revealed that Tom had waited for six weeks before sending the email. Russell expressed satisfaction with the solution and looked forward to seeing BIP 134 updated accordingly. On 21 November 2016, Russell O'Connor expressed concern about Tom's proposal to change the semantics of OP_CHECKSIG in version 2 of 'script', deeming it too naive. Tom had previously explained that in version 2, the data signed would be equivalent to the transaction-id, simplifying the process. However, Tom responded to Russell's email stating that the issue had already been fixed and thanked him for the review after the six-week wait. Tom also provided links to his blog and vlog.The proposal to change the semantics of OP_CHECKSIG in version 2 of script suggested altering the signed data to align with the transaction-id, streamlining the process. However, critics argue that this proposal is overly simplistic. They explain that the SIGHASH data utilized in both Bitcoin script and Segwit script contains information indicating which input is being signed. By signing only the transaction id, the proposed signature fails to include the data specifying which input of the transaction is being signed. Consequently, if different inputs share the same public key due to key reuse, the signatures on those inputs will be identical. Additionally, the Flexible Transactions proposal introduces a new vulnerability to Bitcoin that currently does not exist.An example is given to illustrate this flaw, where two individuals jointly prepare a transaction with one input from each person. If one individual deceives the other by using the outpoint from the other person's transaction, which has the same public key as their chosen input, they can duplicate the signature provided by the other person and fund both inputs for the "jointly" funded purchase. This flaw is considered to be on par with transaction malleability, which is already being addressed. Therefore, caution and vigilance are necessary to avoid this trap, requiring unexpected work. It is advised not to expose Bitcoin to this line of attack. Consequently, it is crucial to thoroughly comprehend the reasons behind existing processes before proposing changes.
Updated on: 2023-08-01T19:14:50.325199+00:00