diff options
| author | Jeremy <jlrubin@mit.edu> | 2019-06-22 23:43:22 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-06-23 06:43:37 +0000 |
| commit | 3b2343d6501cded14e88df5a4a37f3c220bfb9eb (patch) | |
| tree | 9f8ab83f64c40a2caa9bcaedd37b43f74324403f /1f | |
| parent | c8a9bf8dae44482efa02edf7213929eadc301117 (diff) | |
| download | pi-bitcoindev-3b2343d6501cded14e88df5a4a37f3c220bfb9eb.tar.gz pi-bitcoindev-3b2343d6501cded14e88df5a4a37f3c220bfb9eb.zip | |
Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
Diffstat (limited to '1f')
| -rw-r--r-- | 1f/746bfb89ac77a0942163a4d58f831c9c3f64ce | 220 |
1 files changed, 220 insertions, 0 deletions
diff --git a/1f/746bfb89ac77a0942163a4d58f831c9c3f64ce b/1f/746bfb89ac77a0942163a4d58f831c9c3f64ce new file mode 100644 index 000000000..b90464c3b --- /dev/null +++ b/1f/746bfb89ac77a0942163a4d58f831c9c3f64ce @@ -0,0 +1,220 @@ +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 C6D221986 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 23 Jun 2019 06:43:37 +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 091A8710 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 23 Jun 2019 06:43:36 +0000 (UTC) +Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com + [209.85.208.51]) (authenticated bits=0) + (User authenticated as jlrubin@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5N6hYuZ025774 + (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 23 Jun 2019 02:43:35 -0400 +Received: by mail-ed1-f51.google.com with SMTP id z25so16390116edq.9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 22 Jun 2019 23:43:35 -0700 (PDT) +X-Gm-Message-State: APjAAAXDfRsp20rOcT4G518h9yMpVtLIHJn5m0Gusp2NOOMqnRhYL9TT + 41unDDmoPTrGpMBTJBvfX9NnNZ3J1DaOzCUTcsI= +X-Google-Smtp-Source: APXvYqx4WZYaBOZFCv6pz/C/ZR7IBcG3enMpdvjNuFcUCHSzvGoRuaBbGypbGuDN6COivZrJcNotrEwZo9qhcwdDZjc= +X-Received: by 2002:aa7:cfc3:: with SMTP id r3mr24135619edy.202.1561272213949; + Sat, 22 Jun 2019 23:43:33 -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> + <CAMZUoK=ZB06jwAbuX2D=aN8ztAqr_jSgEXS1z1ABjQYVawKCBQ@mail.gmail.com> + <20190620220552.metrqaul3iporwma@erisian.com.au> +In-Reply-To: <20190620220552.metrqaul3iporwma@erisian.com.au> +From: Jeremy <jlrubin@mit.edu> +Date: Sat, 22 Jun 2019 23:43:22 -0700 +X-Gmail-Original-Message-ID: <CAD5xwhgEQKdTCSLQn4-X_atT5_aE-1hEKk0xd1wm1m0qotwYXQ@mail.gmail.com> +Message-ID: <CAD5xwhgEQKdTCSLQn4-X_atT5_aE-1hEKk0xd1wm1m0qotwYXQ@mail.gmail.com> +To: Anthony Towns <aj@erisian.com.au>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000b5d27a058bf80305" +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: Sun, 23 Jun 2019 16:34:08 +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: Sun, 23 Jun 2019 06:43:37 -0000 + +--000000000000b5d27a058bf80305 +Content-Type: text/plain; charset="UTF-8" + +This is insufficient: sequences must be committed to because they affect +TXID. As with scriptsigs (witness data fine to ignore). NUM_IN too. + +Any malleability makes this much less useful. +-- +@JeremyRubin <https://twitter.com/JeremyRubin> +<https://twitter.com/JeremyRubin> + + +On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote: +> > 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." +> +> Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT +> (NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if +> it's been spelled out anywhere); ie instead of constructing +> +> X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in ) +> +> and having the script be "<X> OP_SECURETHEBAG" you calculate an +> ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL: +> +> Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0, +> amount, sequence) +> +> and calculate a signature sig = Schnorr(P,m) for some pubkey P, and +> make your script be "<sig> <P> CHECKSIG". +> +> That loses the ability to commit to the number of inputs or restrict +> the nsequence of other inputs, and requires a bigger script (sig and P +> are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the +> same as far as I can tell. Both scripts are automatically satisfied when +> revealed (with the correct set of outputs), and don't need any additional +> witness data. +> +> If you wanted to construct "X" via script instead of hardcoding a value +> because it got you generalised covenants or whatever; I think you could +> get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much +> the same way you construct X, but you'd then need to turn that into a +> signature. You could do so by using pubkey P=G and nonce R=G, which +> means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash +> part is easy, multiplying it by 1 is easy, and to add 1 you can probably +> do something along the lines of: +> +> OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT +> +> (ie, take the last 4 bytes, increment it using 4-byte arithmetic, +> then cat the first 28 bytes and the result. There's overflow issues, +> but I think they can be worked around either by allowing you to choose +> different locktimes, or by more complicated script) +> +> Cheers, +> aj +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--000000000000b5d27a058bf80305 +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">This is insufficient: seq= +uences must be committed to because they affect TXID. As with scriptsigs (w= +itness data fine to ignore). NUM_IN too.</div><div class=3D"gmail_default" = +style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000= +00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve= +tica,sans-serif;font-size:small;color:#000000">Any malleability makes this = +much less useful.<br></div><div><div dir=3D"ltr" class=3D"gmail_signature" = +data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https:= +//twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"htt= +ps://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br><= +/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O= +n Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <<a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo= +undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= +g-left:1ex">On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor = +wrote:<br> +> So with regards to OP_SECURETHEBAG, I am also "not really seeing = +any reason to<br> +> complicate the spec to ensure the digest is precommitted as part of th= +e<br> +> opcode."<br> +<br> +Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT<br> +(NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if= +<br> +it's been spelled out anywhere); ie instead of constructing<br> +<br> +=C2=A0 X =3D Hash_BagHash( version, locktime, [outputs], [sequences], num_i= +n )<br> +<br> +and having the script be "<X> OP_SECURETHEBAG" you calculat= +e an<br> +ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:<br> +<br> +=C2=A0 Y =3D Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= +=A0 =C2=A0amount, sequence)<br> +<br> +and calculate a signature sig =3D Schnorr(P,m) for some pubkey P, and<br> +make your script be "<sig> <P> CHECKSIG".<br> +<br> +That loses the ability to commit to the number of inputs or restrict<br> +the nsequence of other inputs, and requires a bigger script (sig and P<br> +are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much th= +e<br> +same as far as I can tell. Both scripts are automatically satisfied when<br= +> +revealed (with the correct set of outputs), and don't need any addition= +al<br> +witness data.<br> +<br> +If you wanted to construct "X" via script instead of hardcoding a= + value<br> +because it got you generalised covenants or whatever; I think you could<br> +get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much= +<br> +the same way you construct X, but you'd then need to turn that into a<b= +r> +signature. You could do so by using pubkey P=3DG and nonce R=3DG, which<br> +means you need to calculate s=3D1+hash(G,G,Y)*1 -- calculating the hash<br> +part is easy, multiplying it by 1 is easy, and to add 1 you can probably<br= +> +do something along the lines of:<br> +<br> +=C2=A0 =C2=A0 OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT<= +br> +<br> +(ie, take the last 4 bytes, increment it using 4-byte arithmetic,<br> +then cat the first 28 bytes and the result. There's overflow issues,<br= +> +but I think they can be worked around either by allowing you to choose<br> +different locktimes, or by more complicated script)<br> +<br> +Cheers,<br> +aj<br> +<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> + +--000000000000b5d27a058bf80305-- + |