Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A65B2C000B for ; 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 ; 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 ; 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 ; Fri, 28 Jan 2022 13:56:38 +0000 (UTC) Received: by mail-qk1-x734.google.com with SMTP id q5so5585196qkc.1 for ; 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: <20220128013436.GA2939@erisian.com.au> In-Reply-To: <20220128013436.GA2939@erisian.com.au> From: "Russell O'Connor" Date: Fri, 28 Jan 2022 08:56:25 -0500 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. > ' CHECKSIGVERIFY can be simulated by ' > TXHASH 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 " CHECKSIGVERIFY" with > "TXHASH

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

On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns <aj@erisian.com.au> wrote:
> An Alternative P= roposal::
>=C2=A0 ...

> For similar reasons, TXHASH is not amenable to extending the set of tx= flags
> 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.=C2=A0 For examp= le having
> bits to control whether [...]

I don't think that's really feasible -- eg, what you propose don= 9;t cover
SIGHASH_GROUP:

=C2=A0https://lists.lin= uxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html

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.
=C2=A0
> That all said, even if other txhash flag modes are needed in the futur= e,
> 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,<= br> 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 tak= ing
the pubkey "P", marking it as "APO-capable" (by prefixi= ng 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> CHECKSIGVERIF= Y" with
"TXHASH <P> CSFSV" with the witness providing both the sign= ature and
txhash flag, just as separate elements rather than concatenated. (The
"APO-capable" part is implicit in the "TXHASH" opcode)<= br>

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.
=
=C2=A0
> In addition to the CTV and ANYPREVOUT applications, with
> CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages=
> signed by oracles for oracle applications.=C2=A0 This is where we see = the
> benefit of decomposing operations into primitive pieces.=C2=A0 By givi= ng users
> the ability to program their own use cases from components, we get mor= e
> 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&#= 39;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)s= ig or
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
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
algorithms" here...

Which operatio= ns in Script are actually composable today?

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.

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.

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.

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.

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>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.

--000000000000acf9a105d6a4cdf1--