Published on: 2017-09-21T16:33:16+00:00
On September 21, 2017, a discussion took place regarding the understanding of SigAgg, a softfork that aggregates signatures on bitcoin transactions. The possibility of old clients comprehending the aggregation produced by new clients was debated. It was suggested that more witness space could be utilized to store (pubkey, message) pairs, enabling old clients to understand the aggregation. However, this approach was deemed counterproductive as it defeated the purpose of aggregation.It was clarified that since SigAgg is a softfork, old clients would not be able to understand it. An alternative solution was proposed, which involved implying stack items if the Script engine is designed to support it upfront. This would allow the engine to behave as if it were non-verify while maintaining backward compatibility. When questioned about how an OP_MUL could be derived from an OP_NOP, it was explained that new clients would execute it as an OP_MUL and inject pops/pushes when sending the transaction to older clients. This suggested approach would likely need to be part of a MAST-like softfork to be feasible.Johnson Lau addressed the issue of OP_RETURNTRUE not working well with signature aggregation in a message on the Bitcoin development mailing list. Signature aggregation combines (pubkey, message) pairs in a transaction and verifies them with one signature. However, for old nodes, the script terminates at OP_RETURNTRUE, thereby preventing the collection of the (pubkey, message) pair. Lau proposed transforming OP_RETURNTRUE into OP_17 via a softfork. This would enable new nodes to collect the (pubkey, message) pair and attempt to aggregate it with other pairs, potentially resulting in a hardfork.Luke Dashjr countered that this issue should be addressed by signature aggregation itself, rather than relying on modifying OP_RETURNTRUE. Dashjr suggested setting up signature aggregation upfront and having the Script verify the inclusion of keys in the aggregation. Another suggestion made by Dashjr was to create any opcode with an OP_NOP. For instance, if an OP_MUL is desired, an OP_MULVERIFY could be introduced, which would verify if the 3rd stack item is the product of the top 2 stack items.During the discussion session, the idea of maintaining tail-call semantics through the use of the alt stack for transferring arguments to the policy script was proposed. Additionally, a question arose regarding whether this could be considered a bug in the cleanstack rule. The participants also deliberated on the notion of replacing all NOPs and unallocated opcodes with a new OP_RETURNTRUE implementation in future versions of Script. This would cause the program to immediately exit, potentially performing semantic checks on the remaining script. The advantage of this approach is that it allows for softforking in any new opcode, not limited to the -VERIFY opcode variants that have been introduced. Old nodes would always succeed immediately upon encountering an undefined opcode, granting the new opcode the ability to perform any action from that point onward. It should be noted that while this approach is similar to CVE-2010-5141, it shouldn't be exploitable as signatures are no longer treated as scripts themselves.
Updated on: 2023-08-01T21:54:12.251453+00:00