path: root/bf/0fde75c47a8165e7344b189cfccf1a48988c2d

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 &lt;<a href=3D"mailto:=
aj@erisian.com.au" target=3D"_blank">aj@erisian.com.au</a>&gt; 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">&gt; An Alternative P=
roposal::<br>
&gt;=C2=A0 ...<br>
<br>
&gt; For similar reasons, TXHASH is not amenable to extending the set of tx=
flags<br>
&gt; at a later date.<br>
<br>
&gt; I believe the difficulties with upgrading TXHASH can be mitigated by<b=
r>
&gt; designing a robust set of TXHASH flags from the start.=C2=A0 For examp=
le having<br>
&gt; bits to control whether [...]<br>
<br>
I don&#39;t think that&#39;s really feasible -- eg, what you propose don&#3=
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">
&gt; That all said, even if other txhash flag modes are needed in the futur=
e,<br>
&gt; 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 &quot;0xBB&quot; 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=
&#39;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">
&gt; &#39;&lt;anyprevout-pubkey&gt; CHECKSIGVERIFY can be simulated by &#39=
;&lt;apo_style_flag&gt; TXHASH &lt;pubkey&gt; CHECKSIGFROMSTACKVERIFY&#39;.=
 <br>
<br>
I don&#39;t think that&#39;s quite right. BIP 118 anyprevout is done by tak=
ing<br>
the pubkey &quot;P&quot;, marking it as &quot;APO-capable&quot; (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 &quot;&lt;APO:P&gt; CHECKSIGVERIF=
Y&quot; with<br>
&quot;TXHASH &lt;P&gt; CSFSV&quot; with the witness providing both the sign=
ature and<br>
txhash flag, just as separate elements rather than concatenated. (The<br>
&quot;APO-capable&quot; part is implicit in the &quot;TXHASH&quot; 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&#39;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">
&gt; In addition to the CTV and ANYPREVOUT applications, with<br>
&gt; CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages=
<br>
&gt; signed by oracles for oracle applications.=C2=A0 This is where we see =
the<br>
&gt; benefit of decomposing operations into primitive pieces.=C2=A0 By givi=
ng users<br>
&gt; the ability to program their own use cases from components, we get mor=
e<br>
&gt; applications out of fewer op codes!<br>
<br>
While I see the appeal of this from a language design perspective;<br>
I&#39;m not sure it&#39;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 &quot;do everything at once&quot; things like check(multi)s=
ig or<br>
sha256. It seems like what&#39;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 &quot;program their own use cases from<=
br>
components&quot; seems to be coming pretty close to &quot;write your own cr=
ypto<br>
algorithms&quot; 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&#39;s haven&#39;t been composing programs, not because=
 they don&#39;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&#39;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--