diff options
| author | Russell O'Connor <roconnor@blockstream.com> | 2022-01-28 08:56:25 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-28 13:56:40 +0000 |
| commit | 19646d84ca85cf5acdcde91a6f23c1ebc14cf9b4 (patch) | |
| tree | aee80b25891e0d94d1eeeee3b09512eb437da70c | |
| parent | 69b44bd1587f676aca09cff94a2f9a0c9bf2d43e (diff) | |
| download | pi-bitcoindev-19646d84ca85cf5acdcde91a6f23c1ebc14cf9b4.tar.gz pi-bitcoindev-19646d84ca85cf5acdcde91a6f23c1ebc14cf9b4.zip | |
Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
| -rw-r--r-- | bf/0fde75c47a8165e7344b189cfccf1a48988c2d | 334 |
1 files changed, 334 insertions, 0 deletions
diff --git a/bf/0fde75c47a8165e7344b189cfccf1a48988c2d b/bf/0fde75c47a8165e7344b189cfccf1a48988c2d new file mode 100644 index 000000000..5ad011742 --- /dev/null +++ b/bf/0fde75c47a8165e7344b189cfccf1a48988c2d @@ -0,0 +1,334 @@ +Return-Path: <roconnor@blockstream.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A65B2C000B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 13:56:40 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 7F04441650 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 13:56:40 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.899 +X-Spam-Level: +X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) + header.d=blockstream-com.20210112.gappssmtp.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id siV7MeLuzCR1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 13:56:39 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com + [IPv6:2607:f8b0:4864:20::734]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 168514164B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 13:56:38 +0000 (UTC) +Received: by mail-qk1-x734.google.com with SMTP id q5so5585196qkc.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 05:56:38 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=blockstream-com.20210112.gappssmtp.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to; + bh=bbmvDV1SlMEEcB1TQaMl3XKpHL+B5H2ky0Gqgt9qokk=; + b=t/rMouf6DBgLr+RXOZquaPi6hJmEWn4o9XLBjO64aJi/moQpNUZm4KbhWwvS2YYDTg + nTQXvhktBcGoezbEpwQCDLnpGjav1g8OAvLKGSWorQDzwVLAmFcwWyZaWhb8tR/QgFd6 + 2XqgJyplALiT8jP/mHdsW1ueHZgxcZr9Lu6YX7ALLt3QwPCmlX62BsbTvubwmf3mR8Ak + u6Hr1z/ceh7jCbHGX+NYBO+N1Dwbo61KAbw/4FFnnJsxBFsu5+TblTJJSlaYtgK2u7z3 + LwfB04iZ5YhBC0LFTYDn53lozSj69o4+rm7+/sgoanYZj4RTDSTznG8Zl+4SutKJ7j1R + P8Mw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to; + bh=bbmvDV1SlMEEcB1TQaMl3XKpHL+B5H2ky0Gqgt9qokk=; + b=tZvvJMNXUN+MxMTRTKvRgqKpfDcgvQi+lBxugrSHxb61hQVxoz/CxjSmsNCe7Um4h1 + ylYg2lzM+YJWzYA0dP6Kz2fFPHggaimc7d19ROSy5DaSFLAZLGR5Dm6MWIP6NPL6vahH + 6nmYPYlHhBKhc4ZnUhWw2h9D5xNVZD6fYxphAHQz0Ufzgxll4EBX3Zjg7njev6le+F+j + +n0vT8LoSzwlx9KWP0L/VN6bSwhIZvHqtnD2X6eBebhvvPbYl1tNcUbApPZNBl2N0M6y + tGXzoehxMzGuOwLkeMN4Ob1AfJir8J1qquM0aZHc0ZuR9ZalE+kneWvUy0exKsFgn+rH + xa4A== +X-Gm-Message-State: AOAM533Qm9fHUMmoD75zbGMziCx5IqL9RslOwn8j0JWAO49Rz/feV0du + 9xNd9YBknJPhxtt6ULHjnZylSG9fH/ilX82Bya+ZpZ2Kxpo= +X-Google-Smtp-Source: ABdhPJxl323OQzAozPLrarby54wOVSmtpf6RluoM31TjyjOXbPsONF7hNhEkZN3ldRCA026DesVDMV10ONnBhAMJWSM= +X-Received: by 2002:a05:620a:14b3:: with SMTP id + x19mr5525057qkj.310.1643378197192; + Fri, 28 Jan 2022 05:56:37 -0800 (PST) +MIME-Version: 1.0 +References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com> + <20220128013436.GA2939@erisian.com.au> +In-Reply-To: <20220128013436.GA2939@erisian.com.au> +From: "Russell O'Connor" <roconnor@blockstream.com> +Date: Fri, 28 Jan 2022 08:56:25 -0500 +Message-ID: <CAMZUoK=U_-ah3cQbESE8hBXOvSMpxJJd1-ca0mYo7SvMi7izYQ@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000acf9a105d6a4cdf1" +Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV + and ANYPREVOUT +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +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: Fri, 28 Jan 2022 13:56:40 -0000 + +--000000000000acf9a105d6a4cdf1 +Content-Type: text/plain; charset="UTF-8" + +On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns <aj@erisian.com.au> wrote: + +> > An Alternative Proposal:: +> > ... +> +> > For similar reasons, TXHASH is not amenable to extending the set of +> txflags +> > at a later date. +> +> > I believe the difficulties with upgrading TXHASH can be mitigated by +> > designing a robust set of TXHASH flags from the start. For example +> having +> > bits to control whether [...] +> +> I don't think that's really feasible -- eg, what you propose don't cover +> SIGHASH_GROUP: +> +> +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html +> + +For more complex interactions, I was imagining combining this TXHASH +proposal with CAT and/or rolling SHA256 opcodes. If TXHASH ended up +supporting relative or absolute input/output indexes then users could +assemble the hashes of the particular inputs and outputs they care about +into a single signed message. + + +> > That all said, even if other txhash flag modes are needed in the future, +> > adding TXHASH2 always remains an option. +> +> I think baking this in from day 0 might be better: make TXHASH be +> a multibyte opcode, so that when you decode "0xBB" on the stack, +> you also decode a serialize.h:VarInt as the version number. + + +I wouldn't be opposed to this. + +> '<anyprevout-pubkey> CHECKSIGVERIFY can be simulated by '<apo_style_flag> +> TXHASH <pubkey> CHECKSIGFROMSTACKVERIFY'. +> +> I don't think that's quite right. BIP 118 anyprevout is done by taking +> the pubkey "P", marking it as "APO-capable" (by prefixing it with 0x01), +> and then getting a sighash and sig from the witness. Doing the same +> with TXHASH/CSFSV would just be replacing "<APO:P> CHECKSIGVERIFY" with +> "TXHASH <P> CSFSV" with the witness providing both the signature and +> txhash flag, just as separate elements rather than concatenated. (The +> "APO-capable" part is implicit in the "TXHASH" opcode) +> + +Indeed. The TXHASH variant does require splitting the signature and txhash +flag across two stack items. So it wouldn't be an operationally identical +drop in replacement. + + +> > In addition to the CTV and ANYPREVOUT applications, with +> > CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages +> > signed by oracles for oracle applications. This is where we see the +> > benefit of decomposing operations into primitive pieces. By giving users +> > the ability to program their own use cases from components, we get more +> > applications out of fewer op codes! +> +> While I see the appeal of this from a language design perspective; +> I'm not sure it's really the goal we want. When I look at bitcoin's +> existing script, I see a lot of basic opcodes to do simple arithmetic and +> manipulate the stack in various ways, but the opcodes that are actually +> useful are more "do everything at once" things like check(multi)sig or +> sha256. It seems like what's most useful on the blockchain is a higher +> level language, rather than more of blockchain assembly language made +> up of small generic pieces. I guess "program their own use cases from +> components" seems to be coming pretty close to "write your own crypto +> algorithms" here... +> + +Which operations in Script are actually composable today? + +CHECKSIG composes with nothing else (other than possibly other CHECKSIGs) +as there are no other operations that manipulate pubkey keys or signature +data. + +CLTV and CSV in principle can be composed with addition and subtraction and +comparison operations. But where are you going to get other values to add +and subtract from? I suppose you could compare the relative and absolute +locktimes to each other. + +What do the HASH functions compose with? Without CAT you cannot construct +messages to hash. You can hash the result of the arithmetic operations, +but you are limited to hashing 32-bit (or 33-bit if you are generous) +strings, which is too little entropy to have any security properties. You +can hash a public key or a signature I suppose. + +I don't think there is much in the way of lessons to be drawn from how we +see Bitcoin Script used today with regards to programs built out of +reusable components. User's haven't been composing programs, not because +they don't find composition useful, but rather because the existing +primitives do not lend themselves to being composed at all. + +There is one aspect of Bitcoin Script that is composable, which is +(monotone) boolean combinations of the few primitive transaction conditions +that do exist. The miniscript language captures nearly the entirety of +what is composable in Bitcoin Script today: which amounts to conjunctions, +disjunctions (and thresholds) of signatures, locktimes, and revealing hash +preimages. + +TXHASH + CSFSV won't be enough by itself to allow for very interesting +programs Bitcoin Script yet, we still need CAT and friends for that, but +CSFSV is at least a step in that direction. CSFSV can take arbitrary +messages and these messages can be fixed strings, or they can be hashes of +strings (that need to be revealed), or they can be hashes returned from +TXHASH, or they can be locktime values, or they can be values that are +added or subtracted from locktime values, or they can be values used for +thresholds, or they can be other pubkeys for delegation purposes, or they +can be other signatures ... for who knows what purpose. + +--000000000000acf9a105d6a4cdf1 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= +_attr">On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns <<a href=3D"mailto:= +aj@erisian.com.au" target=3D"_blank">aj@erisian.com.au</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">> An Alternative P= +roposal::<br> +>=C2=A0 ...<br> +<br> +> For similar reasons, TXHASH is not amenable to extending the set of tx= +flags<br> +> at a later date.<br> +<br> +> I believe the difficulties with upgrading TXHASH can be mitigated by<b= +r> +> designing a robust set of TXHASH flags from the start.=C2=A0 For examp= +le having<br> +> bits to control whether [...]<br> +<br> +I don't think that's really feasible -- eg, what you propose don= +9;t cover<br> +SIGHASH_GROUP: <br> +<br> +=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20= +21-July/019243.html" rel=3D"noreferrer" target=3D"_blank">https://lists.lin= +uxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html</a><br></block= +quote><div><br></div><div>For more complex interactions, I was imagining co= +mbining this TXHASH proposal with CAT and/or rolling SHA256 opcodes.=C2=A0 = +If TXHASH ended up supporting relative or absolute input/output indexes the= +n users could assemble the hashes of the particular inputs and outputs they= + care about into a single signed message.<br></div><div>=C2=A0 <br></div><b= +lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= +ft:1px solid rgb(204,204,204);padding-left:1ex"> +> That all said, even if other txhash flag modes are needed in the futur= +e,<br> +> adding TXHASH2 always remains an option.<br> +<br> +I think baking this in from day 0 might be better: make TXHASH be<br> +a multibyte opcode, so that when you decode "0xBB" on the stack,<= +br> +you also decode a serialize.h:VarInt as the version number.</blockquote></d= +iv><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">I wouldn= +'t be opposed to this.<br></div><div class=3D"gmail_quote"><br><blockqu= +ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= + solid rgb(204,204,204);padding-left:1ex"> +> '<anyprevout-pubkey> CHECKSIGVERIFY can be simulated by '= +;<apo_style_flag> TXHASH <pubkey> CHECKSIGFROMSTACKVERIFY'.= + <br> +<br> +I don't think that's quite right. BIP 118 anyprevout is done by tak= +ing<br> +the pubkey "P", marking it as "APO-capable" (by prefixi= +ng it with 0x01),<br> +and then getting a sighash and sig from the witness. Doing the same<br> +with TXHASH/CSFSV would just be replacing "<APO:P> CHECKSIGVERIF= +Y" with<br> +"TXHASH <P> CSFSV" with the witness providing both the sign= +ature and<br> +txhash flag, just as separate elements rather than concatenated. (The<br> +"APO-capable" part is implicit in the "TXHASH" opcode)<= +br></blockquote><div><br></div><div>Indeed. The TXHASH variant does require= + splitting the signature and txhash flag across two stack items.=C2=A0 So i= +t wouldn't be an operationally identical drop in replacement.<br></div>= +<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +> In addition to the CTV and ANYPREVOUT applications, with<br> +> CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages= +<br> +> signed by oracles for oracle applications.=C2=A0 This is where we see = +the<br> +> benefit of decomposing operations into primitive pieces.=C2=A0 By givi= +ng users<br> +> the ability to program their own use cases from components, we get mor= +e<br> +> applications out of fewer op codes!<br> +<br> +While I see the appeal of this from a language design perspective;<br> +I'm not sure it's really the goal we want. When I look at bitcoin&#= +39;s<br> +existing script, I see a lot of basic opcodes to do simple arithmetic and<b= +r> +manipulate the stack in various ways, but the opcodes that are actually<br> +useful are more "do everything at once" things like check(multi)s= +ig or<br> +sha256. It seems like what's most useful on the blockchain is a higher<= +br> +level language, rather than more of blockchain assembly language made<br> +up of small generic pieces. I guess "program their own use cases from<= +br> +components" seems to be coming pretty close to "write your own cr= +ypto<br> +algorithms" here...<br></blockquote><div><br></div><div>Which operatio= +ns in Script are actually composable today?</div><div><br></div><div>CHECKS= +IG composes with nothing else (other than possibly other CHECKSIGs) as ther= +e are no other operations that manipulate pubkey keys or signature data.</d= +iv><div><br></div><div>CLTV and CSV in principle can be composed with addit= +ion and subtraction and comparison operations.=C2=A0 But where are you goin= +g to get other values to add and subtract from?=C2=A0 I suppose you could c= +ompare the relative and absolute locktimes to each other.</div><div><br></d= +iv><div>What do the HASH functions compose with?=C2=A0 Without CAT you cann= +ot construct messages to hash.=C2=A0 You can hash the result of the arithme= +tic operations, but you are limited to hashing 32-bit (or 33-bit if you are= + generous) strings, which is too little entropy to have any security proper= +ties.=C2=A0 You can hash a public key or a signature I suppose.<br></div></= +div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">I don&#= +39;t think there is much in the way of lessons to be drawn from how we see = +Bitcoin Script used today with regards to programs built out of reusable co= +mponents.=C2=A0 User's haven't been composing programs, not because= + they don't find composition useful, but rather because the existing pr= +imitives do not lend themselves to being composed at all.</div><div class= +=3D"gmail_quote"><br></div><div class=3D"gmail_quote">There is one aspect o= +f Bitcoin Script that is composable, which is (monotone) boolean combinatio= +ns of the few primitive transaction conditions that do exist.=C2=A0 The min= +iscript language captures nearly the entirety of what is composable in Bitc= +oin Script today: which amounts to conjunctions, disjunctions (and threshol= +ds) of signatures, locktimes, and revealing hash preimages.<div><br></div><= +div>TXHASH + CSFSV won't be enough by itself to allow for very interest= +ing programs Bitcoin Script yet, we still need CAT and friends for that, bu= +t CSFSV is at least a step in that direction.=C2=A0 CSFSV can take arbitrar= +y messages and these messages can be fixed strings, or they can be hashes o= +f strings (that need to be revealed), or they can be hashes returned from T= +XHASH, or they can be locktime values, or they can be values that are added= + or subtracted from locktime values, or they can be values used for thresho= +lds, or they can be other pubkeys for delegation purposes, or they can be o= +ther signatures ... for who knows what purpose.<br></div><div><br></div></d= +iv></div> + +--000000000000acf9a105d6a4cdf1-- + |