On Wednesday 20 September 2017 5:13:04 AM Johnson Lau wrote: > 2. OP_RETURNTRUE does not work well with signature aggregation. Signature > aggregation will collect (pubkey, message) pairs in a tx, combine them, > and verify with one signature. However, consider the following case: > > OP_RETURNTRUE OP_IF <pubkey> OP_CHECKSIGVERIFY OP_ENDIF OP_TRUE > > For old nodes, the script terminates at OP_RETURNTRUE, and it will not > collect the (pubkey, message) pair. > > If we use a softfork to transform OP_RETURNTRUE into OP_17 (pushing the > number 17 to the stack), new nodes will collect the (pubkey, message) pair > and try to aggregate with other pairs. This becomes a hardfork.
This seems like a problem for signature aggregation to address, not a problem for OP_RETURNTRUE... In any case, I don't think it's insurmountable. Signature aggregation can simply be setup upfront, and have the Script verify inclusion of keys in the aggregation? > Technically, we could create ANY op code with an OP_NOP. For example, if we > want OP_MUL, we could have OP_MULVERIFY, which verifies if the 3rd stack > item is the product of the top 2 stack items. Therefore, OP_MULVERIFY > OP_2DROP is functionally same as OP_MUL, which removes the top 2 items and > returns the product. The problem is it takes more witness space. This is another approach, and one that seems like a good idea in general. I'm not sure it actually needs to take more witness space - in theory, such stack items could be implied if the Script engine is designed for it upfront. Then it would behave as if it were non-verify, while retaining backward compatibility. Luke _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev