Published on: 2015-04-18T23:33:52+00:00
In a discussion on #bitcoin-wizards, Bitcoin Core developer Mike Hearn suggests using OP_CODESEPARATOR to implement efficient payword schemes. He also mentions that early on, this feature allowed for after-the-fact signing delegation. However, the feature was removed without thorough consideration. Satoshi believed in one implementation and put CODESEPARATOR into the scriptSig/scriptPubKey concatenation, making it necessary to opt-in for that feature's use. Without the mis-matched ENDIF, users cannot delegate signing authority after the fact. Stephen Morse proposes a change in nHashType to specify what is serialized for the signature hash, reducing malleability and allowing hardware wallets to sign securely without downloading or processing each transaction. Concerns are raised about creating too many options, leading to a choose-your-own-adventure scenario. The author suggests that eliminating txin txid enables covenants, which are payments that constrain future payments. There are discussions about auto-forwarding, with suggestions to reorder serialization to avoid bottlenecks and the use of CODESEPARATOR to sign code as part of verifying the signature. Jeff Garzik responds to a question about slow transaction verification speed, highlighting issues such as slower propagation, increased node workload, and opportunities for attacks. Peter Todd proposes mechanisms to improve CHECKSIG efficiency. The possibility of auto forwarding and replay attacks is debated, with suggestions to put previous scriptPubKey and output value at the end of serialized transactions. The bottleneck of hashing transaction data once per input is questioned for large transactions. An email exchange between Stephen Morse and Jeff Garzik discusses the potential issues of slow transaction verification speed and the bottleneck for mobile devices. Another conversation between Mike and Stephen explores changing sighash flags for Bitcoin transactions, addressing concerns about practicality, security, and the need to avoid unnecessary hashing. Finally, a proposal is made to allow transaction signers to specify what is serialized for the signature hash, aiming to make malleability a non-issue and enable secure signing for hardware wallets. The proposal can be found on Github, and feedback is welcome.
Updated on: 2023-08-01T12:13:04.750429+00:00