From: Johnson Lau <jl2012@xbt•hk>
To: Luke Dashjr <luke@dashjr•org>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)
Date: Thu, 21 Sep 2017 16:02:42 +0800 [thread overview]
Message-ID: <21D6060D-97F0-439A-86D3-065C21BACC3F@xbt.hk> (raw)
In-Reply-To: <201709210411.50642.luke@dashjr.org>
> On 21 Sep 2017, at 12:11 PM, Luke Dashjr <luke@dashjr•org> wrote:
>
> 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?
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.
We use different skills to save space. For example, we use 1-byte SIGHASH flag to imply the 32-byte message. For maximal space saving, sig aggregation will also rely on such skills. However, the assumption is that all signatures aggregated must follow exactly the same set of rules.
>
>> 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.
Sounds interesting but I don’t get it. For example, how could you make a OP_MUL out of OP_NOP?
>
> Luke
next prev parent reply other threads:[~2017-09-21 8:02 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 0:38 [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Mark Friedenbach
2017-09-08 9:21 ` Johnson Lau
2017-09-12 2:03 ` Mark Friedenbach
2017-09-12 2:13 ` Bryan Bishop
2017-09-12 8:55 ` Johnson Lau
2017-09-12 19:57 ` Mark Friedenbach
2017-09-12 23:27 ` Karl Johan Alm
2017-09-13 9:41 ` Peter Todd
2017-09-11 20:37 ` Adán Sánchez de Pedro Crespo
2017-09-19 0:46 ` Mark Friedenbach
2017-09-19 3:09 ` [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Luke Dashjr
2017-09-19 7:33 ` Mark Friedenbach
2017-09-22 20:32 ` Sergio Demian Lerner
2017-09-22 21:11 ` Mark Friedenbach
2017-09-22 21:32 ` Sergio Demian Lerner
2017-09-22 21:39 ` Mark Friedenbach
2017-09-22 21:54 ` Sergio Demian Lerner
2017-09-22 22:07 ` Mark Friedenbach
2017-09-22 22:09 ` Pieter Wuille
2021-04-09 8:15 ` [bitcoin-dev] maximum block height on transaction Erik Aronesty
2021-04-09 11:39 ` Russell O'Connor
2021-04-09 15:54 ` Jeremy
2021-04-12 20:04 ` Billy Tetrud
2021-04-16 4:24 ` ZmnSCPxj
2021-05-03 2:30 ` ZmnSCPxj
2017-09-20 5:13 ` [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Johnson Lau
2017-09-20 19:29 ` Mark Friedenbach
2017-09-21 3:58 ` Johnson Lau
2017-09-21 4:11 ` Luke Dashjr
2017-09-21 8:02 ` Johnson Lau [this message]
2017-09-21 16:33 ` Luke Dashjr
2017-09-21 17:38 ` Johnson Lau
2017-09-30 23:23 ` [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Luke Dashjr
2017-09-30 23:51 ` Mark Friedenbach
2017-10-02 17:15 ` Russell O'Connor
2017-10-28 4:40 ` Mark Friedenbach
2017-11-01 8:43 ` Luke Dashjr
2017-11-01 15:08 ` Mark Friedenbach
2017-11-04 7:59 ` Luke Dashjr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21D6060D-97F0-439A-86D3-065C21BACC3F@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox