diff options
| author | Russell O'Connor <roconnor@blockstream.io> | 2019-06-18 16:57:34 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-06-18 20:57:47 +0000 |
| commit | f8bbc37d592d5417f885dad3a3fc23055710767f (patch) | |
| tree | e1f6036537d419992566788ca4e806432130cebe | |
| parent | 1c3ca74bbad89d85a8c2d0a6034e407690f2c9e2 (diff) | |
| download | pi-bitcoindev-f8bbc37d592d5417f885dad3a3fc23055710767f.tar.gz pi-bitcoindev-f8bbc37d592d5417f885dad3a3fc23055710767f.zip | |
Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
| -rw-r--r-- | 7a/27deff88f8f565203aae1ae4772f8fa5399dde | 250 |
1 files changed, 250 insertions, 0 deletions
diff --git a/7a/27deff88f8f565203aae1ae4772f8fa5399dde b/7a/27deff88f8f565203aae1ae4772f8fa5399dde new file mode 100644 index 000000000..5c38b9644 --- /dev/null +++ b/7a/27deff88f8f565203aae1ae4772f8fa5399dde @@ -0,0 +1,250 @@ +Return-Path: <roconnor@blockstream.io> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 607C6BB3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jun 2019 20:57:47 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-io1-f49.google.com (mail-io1-f49.google.com + [209.85.166.49]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB8DB180 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jun 2019 20:57:46 +0000 (UTC) +Received: by mail-io1-f49.google.com with SMTP id n5so33076594ioc.7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jun 2019 13:57:46 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=blockstream.io; s=google; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=oquKweOiF2wh7gmq0K6heUHEhKNbIGXGp7h2Wbr9eJ4=; + b=3PNxEz5b75E0LIpgqBjeM82kTZmABLOn6cGAEQjB6LOhOnLb7367vKZOT5oLfl3jMa + RGQJO31MHuvmfNLOTNy5envOOc80VRGjSaBTpEAe8BHc2jSQTdH+rGtj6zHEP/emfPlM + va8kiGriiE4Lds1n0UPVx+NNobjHWW3Ze2vT0= +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=oquKweOiF2wh7gmq0K6heUHEhKNbIGXGp7h2Wbr9eJ4=; + b=qqB93ORb/XAsifG/JLAyS2D54q9UBQJKPmEeTHIRk9mHA1qDM7IZp81+OyABkSq/Zr + zuBfQyUAk9wifosYc47+2b0DgntHpWIJHUir98mfcQdoVRgqEHjCrZCxeD4c7z8lOKON + R6rFYIZKgapBQrixAGoGc0/6G4LJ3D9HNu2madj9CbE3ym6PR5/nLh/jHZJRpu6DVT3d + X5Q/SJ+OudZqv8vKslnrUContjLl5kclw4QWIOZpeOa+e2JWJ8V1DqSYDsoX5Q6ZtgkP + C/lJc+3uxyvQlH8oWJMGN0uDqCz1G+ctqxSmee5EH5+V3tdu71JHP8ExtMVm82aoai3+ + Or4w== +X-Gm-Message-State: APjAAAXeAV5YX/Y9Vb5bExWYLovg7RtYMf77RoLuZ6V2mwfRqIaUUmFV + u+aQa71Z4jocrVLe3MPx/AjrDCxL3Gfi2LA4Qt1UGKk7M28= +X-Google-Smtp-Source: APXvYqxpyvZOVha0S+BQDGqc03MNWYT9Qp76Tpq0qAGCpg+qyAo5KzKFHnZ/fPb5huHTNIwnPnReCqd+vMt1snOqhsc= +X-Received: by 2002:a6b:7208:: with SMTP id n8mr7222366ioc.151.1560891465846; + Tue, 18 Jun 2019 13:57:45 -0700 (PDT) +MIME-Version: 1.0 +References: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com> + <20190605093039.xfo7lcylqkhsfncv@erisian.com.au> + <im0q8670MxshmvMLmoJU0dv4rFhwWZNvQeQYv7i4fBWJOx0ghAdH8fYuQSqNxO2z8uxXGV-kurinUDfl0FsLWD0knw_U_h3zVZ0xy7vmn8o=@protonmail.com> +In-Reply-To: <im0q8670MxshmvMLmoJU0dv4rFhwWZNvQeQYv7i4fBWJOx0ghAdH8fYuQSqNxO2z8uxXGV-kurinUDfl0FsLWD0knw_U_h3zVZ0xy7vmn8o=@protonmail.com> +From: "Russell O'Connor" <roconnor@blockstream.io> +Date: Tue, 18 Jun 2019 16:57:34 -0400 +Message-ID: <CAMZUoK=ZB06jwAbuX2D=aN8ztAqr_jSgEXS1z1ABjQYVawKCBQ@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000005aec7d058b9f5d9c" +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE 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: Thu, 20 Jun 2019 17:59:07 +0000 +Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) +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: Tue, 18 Jun 2019 20:57:47 -0000 + +--0000000000005aec7d058b9f5d9c +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style of +covenants if it pulled data from the stack, the OP_SECURETHEBAG probably +cannot create covenants even if it were to pull the data from the stack +unless some OP_TWEEKPUBKEY operation is added to Script because the +"commitment of the script itself" isn't part of the OP_SECURETHEBAG. + +So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason +to complicate the spec to ensure the digest is precommitted as part of the +opcode." + +On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Good morning aj, +> +> +> Sent with ProtonMail Secure Email. +> +> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = +Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 +> On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote: +> > +> > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. +> > +> > I think you could generalise that slightly and make it fit in +> > with the existing opcode naming by calling it something like +> > "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack, +> > consisting of a sha256 hash and a sighash-byte, and adding a new sighas= +h +> > value corresponding to the set of info you want to include in the hash, +> > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_AL= +L" +> > +> > FWIW, I'm not really seeing any reason to complicate the spec to ensure +> > the digest is precommitted as part of the opcode. +> > +> +> I believe in combination with `OP_LEFT` and `OP_CAT` this allows +> Turing-complete smart contracts, in much the same way as +> `OP_CHECKSIGFROMSTACK`? +> +> Pass in the spent transaction (serialised for txid) and the spending +> transaction (serialised for sighash) as part of the witness of the spendi= +ng +> transaction. +> +> Script verifies that the spending transaction witness value is indeed the +> spending transaction by `OP_SHA256 <SIGHASH_ALL> OP_SWAP OP_CAT +> OP_CHECKTXDIGESTVERIFY`. +> Script verifies the spent transaction witness value is indeed the spent +> transaction by hashing it, then splitting up the hash with `OP_LEFT` into +> bytes, and comparing the bytes to the bytes in the input of the spending +> transaction witness value (txid being the bytes in reversed order). +> +> Then the Script can extract a commitment of itself by extracting the +> output of the spent transaction. +> This lets the Script check that the spending transaction also pays to the +> same script. +> +> The Script can then access a state value, for example from an `OP_RETURN` +> output of the spent transaction, and enforce that a correct next-state is +> used in the spending transaction. +> If the state is too large to fit in a standard `OP_RETURN`, then the +> current state can be passed in as a witness and validated against a hash +> commitment in an `OP_RETURN` output. +> +> I believe this is the primary reason against not pulling data from the +> stack. +> +> Regards, +> ZmnSCPxj +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000005aec7d058b9f5d9c +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Just to be clear, while <span class=3D"gmail-im">OP_C= +HECKTXDIGESTVERIFY would enable this style of covenants if it pulled data f= +rom the stack, the <span class=3D"gmail-im">OP_SECURETHEBAG probably cannot= + create covenants even if it were to pull the data from the stack unless so= +me OP_TWEEKPUBKEY operation is added to Script because the "commitment= + of the script itself" isn't part of the OP_SECURETHEBAG.</span></= +span></div><div><span class=3D"gmail-im"><span class=3D"gmail-im"><br></spa= +n></span></div><div><span class=3D"gmail-im"><span class=3D"gmail-im">So wi= +th regards to OP_SECURETHEBAG, I am also<span class=3D"gmail-im"> "not= + really seeing any reason to complicate the spec to ensure the digest is pr= +ecommitted as part of the opcode."</span></span></span></div><div><spa= +n class=3D"gmail-im"><span class=3D"gmail-im"></span></span></div></div><br= +><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, J= +un 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <<a href=3D"mailto:bitcoi= +n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&= +gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= +px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good = +morning aj,<br> +<br> +<br> +Sent with ProtonMail Secure Email.<br> +<br> +=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= +ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<br> +On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev <<a hr= +ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco= +in-dev@lists.linuxfoundation.org</a>> wrote:<br> +<br> +> On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote= +:<br> +><br> +> > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBA= +G*.<br> +><br> +> I think you could generalise that slightly and make it fit in<br> +> with the existing opcode naming by calling it something like<br> +> "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the s= +tack,<br> +> consisting of a sha256 hash and a sighash-byte, and adding a new sigha= +sh<br> +> value corresponding to the set of info you want to include in the hash= +,<br> +> which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGH= +ASH_ALL"<br> +><br> +> FWIW, I'm not really seeing any reason to complicate the spec to e= +nsure<br> +> the digest is precommitted as part of the opcode.<br> +><br> +<br> +I believe in combination with `OP_LEFT` and `OP_CAT` this allows Turing-com= +plete smart contracts, in much the same way as `OP_CHECKSIGFROMSTACK`?<br> +<br> +Pass in the spent transaction (serialised for txid) and the spending transa= +ction (serialised for sighash) as part of the witness of the spending trans= +action.<br> +<br> +Script verifies that the spending transaction witness value is indeed the s= +pending transaction by `OP_SHA256 <SIGHASH_ALL> OP_SWAP OP_CAT OP_CHE= +CKTXDIGESTVERIFY`.<br> +Script verifies the spent transaction witness value is indeed the spent tra= +nsaction by hashing it, then splitting up the hash with `OP_LEFT` into byte= +s, and comparing the bytes to the bytes in the input of the spending transa= +ction witness value (txid being the bytes in reversed order).<br> +<br> +Then the Script can extract a commitment of itself by extracting the output= + of the spent transaction.<br> +This lets the Script check that the spending transaction also pays to the s= +ame script.<br> +<br> +The Script can then access a state value, for example from an `OP_RETURN` o= +utput of the spent transaction, and enforce that a correct next-state is us= +ed in the spending transaction.<br> +If the state is too large to fit in a standard `OP_RETURN`, then the curren= +t state can be passed in as a witness and validated against a hash commitme= +nt in an `OP_RETURN` output.<br> +<br> +I believe this is the primary reason against not pulling data from the stac= +k.<br> +<br> +Regards,<br> +ZmnSCPxj<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--0000000000005aec7d058b9f5d9c-- + |