On Thursday 21 September 2017 8:02:42 AM Johnson Lau wrote: > I think it’s possible only if you spend more witness space to store the > (pubkey, message) pairs, so that old clients could understand the > aggregation produced by new clients. But this completely defeats the > purpose of doing aggregation.
SigAgg is a softfork, so old clients *won't* understand it... am I missing something? For example, perhaps the lookup opcode could have a data payload itself (eg, like pushdata opcodes do), and the script can be parsed independently from execution to collect the applicable ones. > > 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. > > Sounds interesting but I don’t get it. For example, how could you make a > OP_MUL out of OP_NOP? The same as your OP_MULVERIFY at the consensus level, except new clients would execute it as an OP_MUL, and inject pops/pushes when sending such a transaction to older clients. The hash committed to for the script would include the inferred values, but not the actual on-chain data. This would probably need to be part of some kind of MAST-like softfork to be viable, and maybe not even then. Luke _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
