Author: Mark Friedenbach 2017-10-02 00:35:38
Published on: 2017-10-02T00:35:38+00:00
The email thread discusses three proposals with similar goals but different designs. The first proposal suggests allowing further upgrades within v1 witness by implementing minor versions in the witness. However, this proposal raises concerns about ending up with many minor versions and confusion surrounding the nomenclature. The second proposal suggests using OP_RETURNTRUE, but it is deemed unfit for signature aggregation. The third proposal suggests using the generalized NOP method where users provide the returned value, but it raises issues with VERIFY-type code. Instead of these proposals, the email suggests gate new behavior based on script execution flags, which are set based on the script version. The second question asks whether to allow signature-time commitment of extra scripts. One proposal suggests tail-call semantics with CHECKSIGFROMSTACK, but it only works with specially designed scriptPubKey. The other two proposals suggest using scriptWitCode or Extra-data as script in OP_CHECKSIG. However, the email suggests proposing these as their own script updates instead of creating a complex omnibus overhaul that does everything.Finally, the email addresses whether to allow static analysis of sigop. The email suggests that a v1 witness upgrade should not be coupled with this proposal. Instead, a v1 witness type upgrade should add a proper script version in the witness and remove unnecessary verification rules that hinder progress. For example, the email suggests dropping the CLEANSTACK rule in favor of something else like signatures committing to the witness depth and/or weight. It also suggests dropping the 520 byte push limitation and providing alternatives that support larger serialized proofs.
Updated on: 2023-06-12T21:28:51.686143+00:00