Published on: 2017-10-05T21:28:48+00:00
The email conversation among Bitcoin developers revolves around potential changes to the signature format and Bitcoin scripting. Mark Friedenbach clarifies that an idea proposed by Johnson Lau belongs to Lau and suggests it is uncontroversial. Luke Dashjr proposes a first draft for Segwit and Bitcoin scripting, introducing five changes including a new witness version, eliminating the need to guess signature size, allowing signatures to commit to additional conditions, interpreting the final stack element as a tail-call Script, and making undefined opcodes exit the script with success. Russell O'Connor suggests replacing the requirement in CHECKMULTISIG with a bitfield specifying which pubkeys are used.Friedenbach suggests using script execution flags based on script versions to gate new behavior instead of OP_RETURNTRUE or generalized NOP method. This suggestion breaks parallel soft-fork deployments. Luke Dashjr proposes two new options for BIP114 but later changes his mind. Friedenbach suggests gating new behavior based on script execution flags set by the script version, which also breaks parallel softfork deployments. They discuss allowing signature-time commitment of extra scripts through tail-call semantics, scriptWitCode, or extra-data as script in OP_CHECKSIG. They emphasize the need for planning the overall design/layout in advance.Johnson Lau and Luke Dashjr discuss various options for allowing further upgrades within v1 witness, including using a minor version in the witness with OP_RETURNTRUE as a fallback. They suggest proposing these as their own script updates instead of creating a complex overhaul. They also address whether to allow static analysis of sigop and how it can be done.The email thread discusses three proposals with similar goals but different designs. The first proposal suggests allowing further upgrades within v1 witness using minor versions. The second proposal suggests using OP_RETURNTRUE, but it is unfit for signature aggregation. The third proposal suggests using the generalized NOP method, but it raises issues with VERIFY-type code. Instead, the email suggests gating new behavior based on script execution flags set by the script version. The email also addresses whether to allow signature-time commitment of extra scripts and whether to allow static analysis of sigop.Friedenbach proposes incorporating an optional commitment to witness size in bytes using SIGHASH_WITNESS_SIZE. Script validation flags can prevent malleability issues, but they were not made consensus rules with Segwit v0 due to concerns over scope creep. Friedenbach discusses creating a SIGHASH_WITNESS_WEIGHT flag instead of SIGHASH_WITNESS_DEPTH. O'Connor argues that requiring a counterparty to choose their keys before signing is reasonable in multi-party signing of inputs.The Bitcoin developer community discusses potential changes to the signature format, including easy implementation of cross chain replay protection in future hard forks and eliminating the clean stack consensus requirement. Luke Dashjr proposes a draft for Segwit and Bitcoin scripting with key changes such as introducing minor versions for witnesses, undefined opcodes causing the script to exit with success, a shorter fixed-length signature format, and signatures committing to additional conditions. However, there are still unresolved issues regarding the commitment of the signature to script interpreter flags and internal "sigversion".Luke Dashjr's draft aims to simplify scripting by introducing minor versions for witnesses, allowing undefined opcodes to cause the script to exit with success, and enabling signatures to commit to additional conditions. The CLEANSTACK rule would be eliminated, and the number of items on the stack would be included in the signature hash. There is still an issue regarding the commitment of the signature to the script interpreter flags and internal "sigversion" that needs resolution.Luke Dashjr shares a first draft for potential changes to Segwit and Bitcoin scripting, including minor versions for witnesses, causing the script to exit with success when encountering undefined opcodes, executing a tail-call Script if the final stack element is not true or false, and implementing a new fixed-length signature format. The proposal aims to address replay protection concerns with OP_CHECKBLOCKATHEIGHT (BIP 115). However, the commitment of the signature to script interpreter flags and internal "sigversion" remains a complex issue that needs resolution. Feedback is sought from the community.The email conversation and proposals among Bitcoin developers focus on potential changes to the signature format to enhance flexibility and compatibility with future hard forks. Ideas explored include cross chain replay protection, elimination of the clean stack consensus requirement, and inclusion of the number of witness elements in the signature hash. Luke Dashjr's draft proposes specific changes, but there are unresolved issues that need resolution before deployment. Continuous feedback from the community is encouraged.
Updated on: 2023-08-01T22:00:48.925704+00:00