Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-21 📝 Original message:On Wednesday 20 September ...

📅 Original date posted:2017-09-21
📝 Original message: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