path: root/b3/b5981aa812430f6554c5141acbf1686641775d

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 15996C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 29 Jan 2022 15:43:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id F266C40337
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 29 Jan 2022 15:43:28 +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 DsFXK9Fy3Pwd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 29 Jan 2022 15:43:27 +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 CED6D40336
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 29 Jan 2022 15:43:26 +0000 (UTC)
Received: by mail-qk1-x734.google.com with SMTP id 200so8228851qki.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 29 Jan 2022 07:43:26 -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=mrnrEjDk7S0jBepyegkq+maOnsP9TKTgUUNARVOK0mg=;
 b=WKjCThLNS1B8TAMn+kz9xE0OamhPPIsDcS/WU6Y6jxyMwROU9mt/j6i1ThVoyLBj/z
 80yAZ9sJTCD2iGWXpJNZS89jgP3XCcsKsaJhFI263KXIv8gUOHXqSM2mcMLDsHwgTrF5
 uouRCuESVByxJSVujmS54jYykSLv5rOFIJRaAo/O9umy0EXn++K6TdcRmgQgbLC22jGA
 /2tNXd6C40lQJRy1Ae2ktDoD4MzzkfBBrFnUhFSPgTk0irzy0l3aP1EROfBfShzqOTWC
 nLNWLUr+gaM9XLaFRVvDr5xdYwCEHPOqd9frBX44ednHfADO+gsZuzoGMs6f0QvbDEn3
 0EKQ==
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=mrnrEjDk7S0jBepyegkq+maOnsP9TKTgUUNARVOK0mg=;
 b=SBvtfVDuaWtxdKRYqtMQ4LId3zprqfQoL21tU+uDoN5JRHAPKkQFIJJaBi/Qy7p7Cy
 ntpCz6N8gBdbc7BIovrVPx705md/KKe6hnw+Il8C1CuN1YqeBNWo5R7BQPCeO4QjyC90
 gFfkvMbL9ISPjqimzEvuYRkH8L2zHGwCXCo8l0LTtk2PQBO2HEdAU3uSAZ/1QS7hK0ps
 0RFcFPN3NOVFJt1j5o2HtCC/HuQTSJa7THoq3/9VTVQlBVpxiYyrvZLVqOQFX6/aN0I5
 EI0Uqn3Hq29nylZAfC77Gb+iVulhsSGYrgBAV8j8UU48wC3ZsZCrQAqk4Jw65d6/MKFL
 QvWA==
X-Gm-Message-State: AOAM531urqMxePq48MmCBtFNNBTDVdFRfWZpzrPTCHQeFk92uP1hlunr
 0P8OoVg5aM4266Nn05CGSHlAVQ78Q7q2M+S6sApzCU2eSNI=
X-Google-Smtp-Source: ABdhPJxAdT8EAGriMEfAGUetmF/d/yR7c3ixwySUAN5qgHBoFqr98S2Lr3vlDuc24kFxf3m1wePKj/GUjt3WXu0vNH4=
X-Received: by 2002:a37:9f86:: with SMTP id i128mr8820130qke.640.1643471005310; 
 Sat, 29 Jan 2022 07:43:25 -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>
 <CAMZUoKkvoJs0WtN71A_qRSwToP4YnY707WdW3C-KJYGXsmkjSw@mail.gmail.com>
 <CAPfvXfLWtDvgJYwQCaxnww5jyQkqFsi6aG0OUxtp3Okx_ab7Hw@mail.gmail.com>
In-Reply-To: <CAPfvXfLWtDvgJYwQCaxnww5jyQkqFsi6aG0OUxtp3Okx_ab7Hw@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sat, 29 Jan 2022 10:43:13 -0500
Message-ID: <CAMZUoKkqEx5mh9Aq9XFc=7YPKmfObMzEipECFuWm4e3q_tVEEQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000078758305d6ba6945"
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: Sat, 29 Jan 2022 15:43:29 -0000

--00000000000078758305d6ba6945
Content-Type: text/plain; charset="UTF-8"

On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne <james.obeirne@gmail.com>
wrote:

> > Technical debt isn't a measure of weight of transactions.
>
> Sorry, my original sentence was a little unclear. I meant to say that the
> notion that CTV is just a subpar waypoint en route to a more general
> covenant system may not be accurate if it is a more efficient way (in terms
> of chainstate/weight) to express highly useful patterns like vaults. In
> that case, characterizing CTV as technical debt wouldn't be right.
>

It only costs a few more weight units, on the order of 2 or 3, to use
TXHASH in place of CTV.  Notably, the reverse, using CTV in place of
TXHASH, is much more expensive, requiring more than 32 weight units.


> > Our only option here is to be mindful of the long term implications of
> the design choices we are making today.
>
> Your points are well taken - I don't think anyone is arguing against
> thinking hard about consensus changes. But I have yet to see a proposal for
> covenants that is as efficient on-chain and easy to reason about as CTV is.
>
> I also think there's some value in "legging into" covenants by deploying a
> simple, non-recursive construction like CTV that services some very
> important uses, and then taking as much time as necessary to think about
> how to solve more existential problems, like UTXO scalability, that likely
> require a recursive covenant construction.
>
> There doesn't have to be mutual exclusion in the approaches, especially
> when the maintenance burden of CTV seems to be so low. If we end up
> deploying something that requires a wider variety of in-script hashing, it
> seems likely that CTV's hash will be able to "free ride" on whatever more
> general sighash cache structure we come up with.
>

Perhaps there is some misunderstanding.  TXHASH + CSFSV doesn't allow for
complex or recursive covenants.  Typically CAT is needed, at minimum, to
create those sorts of things.  TXHASH still amounts to deploying a
non-recursive covenant construction.

With regards to CTV, in short my primary criticisms are (1) Push semantics
is preferable to verify semantics, because simulating verify semantics from
push is cheap, while simulating push semantics from verify is not
particularly cheap.
And (2) given Push semantics we ought to have parameters to support both
CTV-style hashes and APO-style hashes (which in the presence of CSFSV gives
us APO applications), and, while we are at it, as many other style hashes
as we can reasonably devise so we don't have to go through yet another
soft-fork process every time someone comes up with a new subset of
transaction data they would like to be hashed for their application.

I understand why CTV was designed with verify semantics: it would like to
be NOP compatible.  That certainly made sense pre-tapscript.  I just
haven't (yet) found the use cases for that compatibility to be compelling
in a post-tapscript world.

--00000000000078758305d6ba6945
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 Fri, Jan 28, 2022 at 10:14 AM James O&#39;Beirne &lt;<a href=3D"m=
ailto:james.obeirne@gmail.com">james.obeirne@gmail.com</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"><div dir=3D"ltr"><div=
 dir=3D"ltr">&gt; Technical debt isn&#39;t a measure of weight of transacti=
ons. <br></div><div dir=3D"ltr"><br></div><div>Sorry, my original sentence =
was a little unclear. I meant to say that the notion that CTV is just a sub=
par waypoint en route to a more general covenant system may not be accurate=
 if it is a more efficient way (in terms of chainstate/weight) to express h=
ighly useful patterns like vaults. In that case, characterizing CTV as tech=
nical debt wouldn&#39;t be right.<br></div></div></blockquote><div><br></di=
v><div>It only costs a few more weight units, on the order of 2 or 3, to us=
e TXHASH in place of CTV.=C2=A0 Notably, the reverse, using CTV in place of=
 TXHASH, is much more expensive, requiring more than 32 weight units.<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"><div=
 dir=3D"ltr"><div></div><div>&gt; Our only option here is to be mindful of =
the long term implications of the design choices we are making today.</div>=
<div><br></div><div>Your points are well taken - I don&#39;t think anyone i=
s arguing against thinking hard about consensus changes. But I have yet to =
see a proposal for covenants that is as efficient on-chain and easy to reas=
on about as CTV is. <br></div><div><br></div><div>I also think there&#39;s =
some value in &quot;legging into&quot; covenants by deploying a simple, non=
-recursive construction like CTV that services some very important uses, an=
d then taking as much time as necessary to think about how to solve more ex=
istential problems, like UTXO scalability, that likely require a recursive =
covenant construction. </div><div><br></div><div>There doesn&#39;t have to =
be mutual exclusion in the approaches, especially when the maintenance burd=
en of CTV seems to be so low. If we end up deploying something that require=
s a wider variety of in-script hashing, it seems likely that CTV&#39;s hash=
 will be able to &quot;free ride&quot; on whatever more general sighash cac=
he structure we come up with.<br></div></div></blockquote><div><br></div><d=
iv>Perhaps there is some misunderstanding.=C2=A0 TXHASH=C2=A0+ CSFSV doesn&=
#39;t allow for complex or recursive covenants.=C2=A0 Typically CAT is need=
ed, at minimum, to create those sorts of things.=C2=A0 TXHASH still amounts=
 to deploying a non-recursive covenant construction.<br></div><div><br></di=
v><div>With regards to CTV, in short my primary criticisms are (1) Push sem=
antics is preferable to verify semantics, because simulating verify semanti=
cs from push is cheap, while simulating push semantics from verify is not p=
articularly cheap.</div><div>And (2) given Push semantics we ought to have =
parameters to support both CTV-style hashes and APO-style hashes (which in =
the presence of CSFSV gives us APO applications), and, while we are at it, =
as many other style hashes as we can reasonably devise so we don&#39;t have=
 to go through yet another soft-fork process every time someone comes up wi=
th a new subset of transaction data they would like to be hashed for their =
application.<br></div><div><br></div><div>I understand why CTV was designed=
 with verify semantics: it would like to be NOP compatible.=C2=A0 That cert=
ainly made sense pre-tapscript.=C2=A0 I just haven&#39;t (yet) found the us=
e cases for that compatibility to be compelling in a post-tapscript world.<=
br></div></div></div>

--00000000000078758305d6ba6945--