Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-21 📝 Original message:On Thursday 21 September ...
📅 Original date posted:2017-09-21
📝 Original message: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
📝 Original message: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