public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: Johnson Lau <jl2012@xbt.hk>
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 04:11:49 +0000	[thread overview]
Message-ID: <201709210411.50642.luke@dashjr.org> (raw)
In-Reply-To: <B8C5E7EF-9062-4431-9B63-06FF855B1D78@xbt.hk>

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


  parent reply	other threads:[~2017-09-21  4:12 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 [this message]
2017-09-21  8:02         ` Johnson Lau
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=201709210411.50642.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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