diff options
| author | Jeremy <jlrubin@mit.edu> | 2019-05-24 18:08:00 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-05-25 01:08:16 +0000 |
| commit | 386246087a8ded6d8f0b4f0e6374e1cb60308891 (patch) | |
| tree | 951464c42389808e7b108c80f6f0bde4bfd18a99 | |
| parent | 3d8602bbc821512888fbf19a330b8b0c7b567d42 (diff) | |
| download | pi-bitcoindev-386246087a8ded6d8f0b4f0e6374e1cb60308891.tar.gz pi-bitcoindev-386246087a8ded6d8f0b4f0e6374e1cb60308891.zip | |
Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
| -rw-r--r-- | 04/94ca39a98f4a922172e3fe4df7f4c545165d6a | 272 |
1 files changed, 272 insertions, 0 deletions
diff --git a/04/94ca39a98f4a922172e3fe4df7f4c545165d6a b/04/94ca39a98f4a922172e3fe4df7f4c545165d6a new file mode 100644 index 000000000..581e629d8 --- /dev/null +++ b/04/94ca39a98f4a922172e3fe4df7f4c545165d6a @@ -0,0 +1,272 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id B8681265 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 25 May 2019 01:08:16 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 941176C5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 25 May 2019 01:08:15 +0000 (UTC) +Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com + [209.85.208.52]) (authenticated bits=0) + (User authenticated as jlrubin@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4P18CbM015295 + (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 24 May 2019 21:08:14 -0400 +Received: by mail-ed1-f52.google.com with SMTP id w11so16768131edl.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 24 May 2019 18:08:13 -0700 (PDT) +X-Gm-Message-State: APjAAAV2bBysbpxDR9gWiwgnKD19dRf1rMyuilpWNWwd2Yln4Dfi2UJa + nnl6lS9ZnOpgRRwNkhlipS9cKlp5UraJl5IbGpM= +X-Google-Smtp-Source: APXvYqwOQai491rSkoktsvjWOrs3GholmLcuade0HwDkDl+qxdcUI5o3r9CUqnmdWkWP+0NHintPrPBWKe/N9PaXmrM= +X-Received: by 2002:a17:906:7cd2:: with SMTP id + h18mr48859262ejp.267.1558746492610; + Fri, 24 May 2019 18:08:12 -0700 (PDT) +MIME-Version: 1.0 +References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com> + <CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com> + <CAMZUoKkA4UFivR4xpFcSRE6ThtYawXh9M8my1HnKv34i4o6FJw@mail.gmail.com> +In-Reply-To: <CAMZUoKkA4UFivR4xpFcSRE6ThtYawXh9M8my1HnKv34i4o6FJw@mail.gmail.com> +From: Jeremy <jlrubin@mit.edu> +Date: Fri, 24 May 2019 18:08:00 -0700 +X-Gmail-Original-Message-ID: <CAD5xwhi9YoJ30xOo++mxqLeeGV7gy5kkucUSGzPJ9BkVVKxbfg@mail.gmail.com> +Message-ID: <CAD5xwhi9YoJ30xOo++mxqLeeGV7gy5kkucUSGzPJ9BkVVKxbfg@mail.gmail.com> +To: "Russell O'Connor" <roconnor@blockstream.io> +Content-Type: multipart/alternative; boundary="000000000000fcb08b0589abf2bd" +X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, + RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Sat, 25 May 2019 12:07:05 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sat, 25 May 2019 01:08:16 -0000 + +--000000000000fcb08b0589abf2bd +Content-Type: text/plain; charset="UTF-8" + +What do you think about having it be OP_CHECK_TXID_TEMPLATE_DATA where the +hash checked is the TXID of the transaction with the inputs set to 0000... +(maybe appended to the fee paid)? + +This allows for a variable number of inputs to be allowed (e.g., one, two, +etc). This also fixes potential bugs around TXID malleability for lightning +like setups (Greg and I discussed in wizards about version malleability). + +Allowing multiple inputs is great for structuring more complex contracts +with multiple nodes paying into the same covenantted transaction. + +Also I personally prefer a RISC+CISC approach -- we should enable the +common paths easily as they are known (didn't you come up with jets?) and +improve security for API users, but also piecemeal enable features in +script to allow for experimentation or custom contracts. +-- +@JeremyRubin <https://twitter.com/JeremyRubin> +<https://twitter.com/JeremyRubin> + + +On Fri, May 24, 2019 at 4:15 PM Russell O'Connor <roconnor@blockstream.io> +wrote: + +> In order of escalating scope of amendments to OP_COSHV, I suggest +> +> 1) Peeking at surrounding data surrounding data should definitely be +> replaced by a pushdata-like op-code that uses the subsequent 32-bytes +> directly. The OP_SUCCESSx upgrade path specifically allows for this, and +> avoids complicating the semantics Bitcoin Script. +> 2) Furthermore, the number-of-input-verification and the +> outputhash-verification operations ought to be split into different opcodes +> as they are logically unrelated. +> 3) Better still, we should instead implement the transaction reflection +> operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputhash +> and number of inputs respectively onto the stack. Recursive covenants +> appear to be effectively impossible without either an OP_TWEEKPUBKEY or an +> OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard +> against placing an arbitrary outputhash onto the stack appears to be wasted +> effort to me. +> 4) If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should most +> definitely prefer (3) instead of OP_COSHV, if we still feel the need to do +> anything at all. It is probably best to have both +> OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations of +> OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just +> OP_CHECKSIGFROMSTACKVERIFY as well. +> +> On the other hand, if we are serious about preferring less per-block +> bandwidth over reusable primitive opcodes for programming, then we should +> instead abandon the RISC-style Bitcoin Script and instead add an +> alternative CISC-style taproot leaf type that directly provides (a +> conjunction of) the various popular common policies: channel opening, +> channel factories, coinjoins, hashlocks, timelocks, congestion control +> etc. Segwit v0 already implements this CISC-style for the single most +> popular policy: single signature verification. +> +> On Fri, May 24, 2019 at 4:51 PM Jeremy <jlrubin@mit.edu> wrote: +> +>> Hi Russell, +>> +>> Thanks for this detailed comparison. The COSHV BIP does include a brief +>> comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more +>> detailed. +>> +>> +>> I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's +>> clearly one of the more flexible options available and would enable a +>> multitude of new use cases. +>> +>> When I originally presented my work on congestion control at Jan 2017 +>> BPASE, I also discussed it as an option for covenants. Unfortunately I +>> think it may be on the edge of too powerful -- there are a lot of use cases +>> and implications from having a potentially recursive covenant. If you see +>> my response to Matt in the OP_COSHV BIP thread I classify it as enabling a +>> non-computationally enumerable set of restrictions. +>> +>> I think also from a developer point of view working with OP_COSHV is much +>> much simpler (maybe this can be abstracted) which will lead to increased +>> adoption. OP_COSHV also uses less per-block bandwidth which also makes it +>> preferable for a measure intended to decongest blocks. Do you know the +>> exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating +>> changes to taproot, can be a single byte. OP_COSHV also has less potential +>> to have a negative interaction with future opcodes we may want like +>> OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we +>> want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK +>> unless there's an exact specification which makes us confident we're +>> hitting all the points. +>> +>> If the main complaint about OP_COSHV is that it peeks at surrounding +>> data, it's also possible to implement it more closely to a multi-byte +>> pushdata opcode or do the template optimization. +>> +>> Lastly, as I have previously noted, OP_LEFT is probably safer to +>> implement than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK +>> scripts. +>> +>> + +--000000000000fcb08b0589abf2bd +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:#000000">What do you think about h= +aving it be OP_CHECK_TXID_TEMPLATE_DATA where the hash checked is the TXID = +of the transaction with the inputs set to 0000... (maybe appended to the fe= +e paid)?</div><div class=3D"gmail_default" style=3D"font-family:arial,helve= +tica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmai= +l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;= +color:#000000">This allows for a variable number of inputs to be allowed (e= +.g., one, two, etc). This also fixes potential bugs around TXID malleabilit= +y for lightning like setups (Greg and I discussed in wizards about version = +malleability).</div><div class=3D"gmail_default" style=3D"font-family:arial= +,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class= +=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:#000000">Allowing multiple inputs is great for structuring mo= +re complex contracts with multiple nodes paying into the same covenantted t= +ransaction.<br></div><div class=3D"gmail_default" style=3D"font-family:aria= +l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class= +=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:#000000">Also I personally prefer a RISC+CISC approach -- we = +should enable the common paths easily as they are known (didn't you com= +e up with jets?) and improve security for API users, but also piecemeal ena= +ble features in script to allow for experimentation or custom contracts.<br= +></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gm= +ail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Jeremy= +Rubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Jer= +emyRubin" target=3D"_blank"></a></div></div></div><br></div><br><div class= +=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 24, 2019= + at 4:15 PM Russell O'Connor <<a href=3D"mailto:roconnor@blockstream= +.io">roconnor@blockstream.io</a>> wrote:<br></div><blockquote class=3D"g= +mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= +,204,204);padding-left:1ex"><div dir=3D"ltr"><div>In order of escalating sc= +ope of amendments to OP_COSHV, I suggest<br></div><div><br></div><div>1) Pe= +eking at surrounding data surrounding data should definitely be replaced by= + a pushdata-like op-code that uses the subsequent 32-bytes directly.=C2=A0 = +The OP_SUCCESSx upgrade path specifically allows for this, and avoids compl= +icating the semantics Bitcoin Script.<br></div><div>2) Furthermore, the num= +ber-of-input-verification and the outputhash-verification operations ought = +to be split into different opcodes as they are logically unrelated.<br></di= +v><div>3) Better still, we should instead implement the transaction reflect= +ion operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputha= +sh and number of inputs respectively onto the stack.=C2=A0 Recursive covena= +nts appear to be effectively impossible without either an OP_TWEEKPUBKEY or= + an OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard a= +gainst placing an arbitrary outputhash onto the stack appears to be wasted = +effort to me.<br></div><div>4) If we anticipate adding OP_CHECKSIGFROMSTACK= +VERIFY, then we should most definitely prefer (3) instead of OP_COSHV, if w= +e still feel the need to do anything at all.=C2=A0 It is probably best to h= +ave both OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations o= +f OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just = +OP_CHECKSIGFROMSTACKVERIFY as well.<br></div><div><br></div><div>On the oth= +er hand, if we are serious about preferring less per-block bandwidth over r= +eusable primitive opcodes for programming, then we should instead abandon t= +he RISC-style Bitcoin Script and instead add an alternative CISC-style tapr= +oot leaf type that directly provides (a conjunction of) the various popular= + common policies: channel opening, channel factories, coinjoins, hashlocks,= + timelocks, congestion control etc.=C2=A0 Segwit v0 already implements this= + CISC-style for the single most popular policy: single signature verificati= +on.<br></div><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" cla= +ss=3D"gmail_attr">On Fri, May 24, 2019 at 4:51 PM Jeremy <<a href=3D"mai= +lto:jlrubin@mit.edu" target=3D"_blank">jlrubin@mit.edu</a>> wrote:<br></= +div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= +der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(= +0,0,0)">Hi Russell,</div><div style=3D"font-family:arial,helvetica,sans-ser= +if;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:ar= +ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks for this = +detailed comparison. The COSHV BIP does include a brief comparison to OP_CH= +ECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more detailed.</div><div = +style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0= +,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-= +size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helv= +etica,sans-serif;font-size:small;color:rgb(0,0,0)">I think that the power f= +rom CHECKSIGFROMSTACKVERIFY is awesome. It's clearly one of the more fl= +exible options available and would enable a multitude of new use cases.</di= +v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo= +r:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-seri= +f;font-size:small;color:rgb(0,0,0)">When I originally presented my work on = +congestion control at Jan 2017 BPASE, I also discussed it as an option for = +covenants. Unfortunately I think it may be on the edge of too powerful -- t= +here are a lot of use cases and implications from having a potentially recu= +rsive covenant. If you see my response to Matt in the OP_COSHV BIP thread I= + classify it as enabling a non-computationally enumerable set of restrictio= +ns. <br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helveti= +ca,sans-serif;font-size:small;color:rgb(0,0,0)">I think also from a develop= +er point of view working with OP_COSHV is much much simpler (maybe this can= + be abstracted) which will lead to increased adoption. OP_COSHV also uses l= +ess per-block bandwidth which also makes it preferable for a measure intend= +ed to decongest blocks. Do you know the exact byte cost for OP_CHECKSIGFROM= +STACK? OP_COSHV scripts, with templating changes to taproot, can be a singl= +e byte. OP_COSHV also has less potential to have a negative interaction wit= +h future opcodes we may want like OP_PUBKEYTWEAK. While we're getting t= +o an exact spec for the features we want in Bitcoin scripting, it's har= +d to sign on to OP_CHECKSIGFROMSTACK unless there's an exact specificat= +ion which makes us confident we're hitting all the points.<br></div><di= +v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb= +(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fon= +t-size:small;color:rgb(0,0,0)">If the main complaint about OP_COSHV is that= + it peeks at surrounding data, it's also possible to implement it more = +closely to a multi-byte pushdata opcode or do the template optimization.</d= +iv><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= +or:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-ser= +if;font-size:small;color:rgb(0,0,0)">Lastly, as I have previously noted, OP= +_LEFT is probably safer to implement than OP_CAT and should be more efficie= +nt for OP_CHECKSIGFROMSTACK scripts.<br></div><br></div> +</blockquote></div></div> +</blockquote></div> + +--000000000000fcb08b0589abf2bd-- + |