path: root/35/236a6ca92de54fd095eb834af31b918d72abd4

Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ACFEEC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 14:13:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 9C36281D65
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 14:13:25 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id rYJAJMYG-L15
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 14:13:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com
 [IPv6:2607:f8b0:4864:20::72a])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 8BF2681D5A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 14:13:24 +0000 (UTC)
Received: by mail-qk1-x72a.google.com with SMTP id b35so5090821qkp.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 06:13:24 -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=WBdp/EqTVK9bD9gTebZz0v8YF4CI7Urjmnb9lxVPanU=;
 b=2OphYNQ2xr4z8jO3L5nFJ+aD48aDdp1PVoKzloDoGDTLmh1bRPLMc8Y0eAlvgZmlyK
 vj5uXdVvaUZ+KcHDY1jlwL0K73qANQpFbMzpopheCRWvX5RQgP3RranQl+AsSFPZeHyz
 cw8bPfXQyk4OOCsWnZ4QvCLwaDUIRP6GeXTsHVPXFwM3E7pcWo1sUe+w5PW5us+MJ8m7
 VGnPIroCCsdQ5QhNcYeqNMXF0YR1k/FSL/1nBWgwXq3XmulL+EQ3snmp+K5s0GPF+YnN
 K/EYzCsDYndhBjovjZ84CThYHyaAhIJHdvaudWhuweNbH2NyC8QYSJT7AF8VDRyIW25L
 JKvw==
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=WBdp/EqTVK9bD9gTebZz0v8YF4CI7Urjmnb9lxVPanU=;
 b=QEq1wFMsThlLcPnXY42Urk+RTDYEx18IP22StL3ZqyiUS3DZ9Mv1PtjrJSY53rdSSR
 sSZ0PlOtnD1qQ8KoWLqvg+a6atmiNabtgZucfLjAzlcqe7W3O5mrAN8xLasQjZNzfSy9
 vHylAFr5bpevMncEpR8kmCTDL+9gNwDaSxPp4q7D3Ghpo7xIDfAN72Ij6L0vEyao5Bye
 h3h5Lh/dCttqNjVvCt8oAJclcfLYerG4aZrYmSsVWHhPOPhUvOWGQ6M1133l4X4azoQG
 WMdBEaOOUUFzpCrTmYbRQwiqWSkZdRlAt3rRXor5NaJmsi87+wjoswY0f7St6lt2sxGR
 t6Ig==
X-Gm-Message-State: AOAM530s974XRFIZv+qyaSGMN3FrtoLmohWCI/13LYWjQ7jb2+tHah4G
 5q/3QWAcTSdet4DBadfqiDfXuqXmfXOjB7gb88Pkd55/is+9+Q==
X-Google-Smtp-Source: ABdhPJy4s/OW0VEFZXY4h6WT/20KEWexB/3h4T2D3x4gp33wfspoMIw4u428yL5HaqQ78hryMR+0hW60exXIzy72Kbk=
X-Received: by 2002:a37:9f86:: with SMTP id i128mr5892973qke.640.1643379203124; 
 Fri, 28 Jan 2022 06:13:23 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <CAD5xwhhwqJ_AETAb3p_zUZmRX-Dzh8J9G984zwEs=KFsGN8aNQ@mail.gmail.com>
 <CAMZUoKmU1cwUAQaBv5m8oo8H3TWBvgsZ_OkQaMC0n0+3cpFtWg@mail.gmail.com>
 <CAPfvXfLr4n6RsS6VbEZR59=MRwAx41Crx88ko8-qnRXW4nFYGA@mail.gmail.com>
In-Reply-To: <CAPfvXfLr4n6RsS6VbEZR59=MRwAx41Crx88ko8-qnRXW4nFYGA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 28 Jan 2022 09:13:11 -0500
Message-ID: <CAMZUoKkvoJs0WtN71A_qRSwToP4YnY707WdW3C-KJYGXsmkjSw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a24a4505d6a50954"
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 14:13:25 -0000

--000000000000a24a4505d6a50954
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne <james.obeirne@gmail.com>
wrote:

> > I don't think implementing a CTV opcode that we expect to largely be
> obsoleted by a TXHASH at a later date is yielding good value from a soft
> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it).
> You're presenting a novel idea that, as far as I know, hasn't had much time
> to bake in public. Like Jeremy, I'm concerned by the combinatorial growth
> of flags and the implications that has for testing. Caching for something
> like TXHASH looks to me like a whole different ballgame relative to CTV,
> which has a single kind of hash.
>

Let's not overstate the concern around the combinatorics of TXHASH.   It's
not like there is a vast amount of cross-flag interaction we are talking
about here.  There are also a combinatorial number of ways of assembling
opcodes in Bitcoin script, but we aren't required to exhaustively test
every single possible Script program.


> Even if we were to adopt something like TXHASH, how long is it going to
> take to develop, test, and release? My guess is "a while" - in the
> meantime, users of Bitcoin are without a vault strategy that doesn't
> require either presigning transactions with ephemeral keys (operationally
> difficult) or multisig configurations that would make Rube Goldberg blush
> (operationally difficult and precarious). The utility of vaulting seems
> underappreciated among consensus devs and it's something I'd like to write
> about soon in a separate post.
>
> > The strongest argument I can make in favour of CTV would be something
> like: "We definitely want bare CTV and if we are going to add CTV to legacy
> script (since we cannot use TXHASH in legacy script), then it is actually
> easier not to exclude it from tapscript, even if we plan to add TXHASH to
> tapscript as well."
>
> Another argument for CTV (which I find especially persuasive) is its
> simplicity - it's relatively easy to reason about and, at this point,
> pretty well understood. It seems like a low-risk change relative to some of
> the other covenant proposals, nearly all of which elicit a good deal of
> headscratching (at least from me) and seem to require not only larger
> on-chain footprints but sizable code changes.
>


> > I am sensitive to technical debt and soft fork processes
>

> If OP_CTV ends up being the most practical approach for vaulting - among
> other things - in terms of weight (which it seems to be at the moment) I
> don't think "technical debt" is an applicable term.
>

Technical debt isn't a measure of weight of transactions.  It's a measure
of the code complexity needed to implement, in this case, a Bitcoin Script
interpreter.

By itself, adding a single new hash format for CTV isn't that complex, and
it is certainly simpler than this TXHASH proposal.  But then we need to add
another two slightly different hash formats for APO support.  And tomorrow
we will need yet another set of transaction hash formats for the next
thing, and so on, with each instance requiring going through its own
soft-fork process.  It is at that point we end up with something more
complicated and with more deployment risk than if we had just done
something like TXHASH at the very beginning.  But unlike other programming
environments, we cannot refactor our way out of such a situation.  We
cannot make a new script version while deprecating the old one.  Our only
option here is to be mindful of the long term implications of the design
choices we are making today.

--000000000000a24a4505d6a50954
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jan 27, 2022 at 7:19 PM James O&#39;Beirne &lt;<a =
href=3D"mailto:james.obeirne@gmail.com" target=3D"_blank">james.obeirne@gma=
il.com</a>&gt; wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">&gt; I don&#39=
;t think implementing a CTV opcode that we expect to largely=20
be obsoleted by a TXHASH at a later date is yielding good value from a=20
soft fork process.</div><div dir=3D"ltr"><br></div><div>This presumes the  =
eventual adoption of TXHASH (or something like it). You&#39;re presenting a=
 novel idea that, as far as I know, hasn&#39;t had much time to bake in pub=
lic. Like Jeremy, I&#39;m concerned by the combinatorial growth of flags an=
d the implications that has for testing. Caching for something like TXHASH =
looks to me like a whole different ballgame relative to CTV, which has a si=
ngle kind of hash.<br></div></div></blockquote><div><br></div><div><div>Let=
&#39;s not overstate the concern around the combinatorics=20
of TXHASH. =C2=A0 It&#39;s not like there is a vast amount of cross-flag in=
teraction we are talking about here.=C2=A0 There are also a combinatorial n=
umber of ways of assembling=20
opcodes in Bitcoin script, but we aren&#39;t required to exhaustively test =
every single
 possible Script program.<br></div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div></div><div>Even if we were to a=
dopt something like TXHASH, how long is it going to take to develop, test, =
and release? My guess is &quot;a while&quot; - in the meantime, users of Bi=
tcoin are without a vault strategy that doesn&#39;t require either presigni=
ng transactions with ephemeral keys (operationally difficult) or multisig c=
onfigurations that would make Rube Goldberg blush (operationally difficult =
and precarious). The utility of vaulting seems underappreciated among conse=
nsus devs and it&#39;s something I&#39;d like to write about soon in a sepa=
rate post.<br></div><div dir=3D"ltr"><div><br></div><div>&gt; The strongest=
 argument I can make in favour of CTV would be something=20
like: &quot;We definitely want bare CTV and if we are going to add CTV to=
=20
legacy script (since we cannot use TXHASH in legacy script), then it is=20
actually easier not to exclude it from tapscript, even if we plan to add
 TXHASH to tapscript as well.&quot;</div><div><br></div><div>Another argume=
nt for CTV (which I find especially persuasive) is its simplicity - it&#39;=
s relatively easy to reason about and, at this point, pretty well understoo=
d. It seems like a low-risk change relative to some of the other covenant p=
roposals, nearly all of which elicit a good deal of headscratching (at leas=
t from me) and seem to require not only larger on-chain footprints but siza=
ble code changes.</div></div></div></blockquote><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><=
div>&gt; I am sensitive to technical debt and soft fork=C2=A0processes</div=
></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>If OP_CTV ends up be=
ing the most practical approach for vaulting - among other things - in term=
s of weight (which it seems to be at the moment) I don&#39;t think &quot;te=
chnical debt&quot; is an applicable term.<br></div></div></div></blockquote=
><div><br></div><div>Technical debt isn&#39;t a measure of weight of transa=
ctions.=C2=A0 It&#39;s a measure of the code complexity needed to implement=
, in this case, a Bitcoin Script interpreter.</div><div><br></div><div>By i=
tself, adding a single new hash format for CTV isn&#39;t that complex, and =
it is certainly simpler than this TXHASH proposal.=C2=A0 But then we need t=
o add another two slightly different hash formats for APO support.=C2=A0 An=
d tomorrow we will need yet another set of transaction hash formats for the=
 next thing, and so on, with each instance requiring going through its own =
soft-fork process.=C2=A0 It is at that point we end up with something more =
complicated and with more deployment risk than if we had just done somethin=
g like TXHASH at the very beginning.=C2=A0 But unlike other programming env=
ironments, we cannot refactor our way out of such a situation.=C2=A0 We can=
not make a new script version while deprecating the old one.=C2=A0 Our only=
 option here is to be mindful of the long term implications of the design c=
hoices we are making today.<br></div></div></div>

--000000000000a24a4505d6a50954--