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>
In-Reply-To: <CAMZUoKkvoJs0WtN71A_qRSwToP4YnY707WdW3C-KJYGXsmkjSw@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Fri, 28 Jan 2022 10:14:12 -0500
Message-ID: <CAPfvXfLWtDvgJYwQCaxnww5jyQkqFsi6aG0OUxtp3Okx_ab7Hw@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cbdf5905d6a5e3ca"
Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV
	and ANYPREVOUT
Precedence: list

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

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

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

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

<div dir=3D"ltr"><div dir=3D"ltr">&gt; Technical debt isn&#39;t a measure o=
f weight of transactions. <br></div><div dir=3D"ltr"><br></div><div>Sorry, =
my original sentence was a little unclear. I meant to say that the notion t=
hat CTV is just a subpar waypoint en route to a more general covenant syste=
m 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, chara=
cterizing CTV as technical debt wouldn&#39;t be right.<br></div><div><br></=
div><div>&gt; Our only option here is to be mindful of the long term implic=
ations of the design choices we are making today.</div><div><br></div><div>=
Your points are well taken - I don&#39;t think anyone is arguing against th=
inking hard about consensus changes. But I have yet to see a proposal for c=
ovenants that is as efficient on-chain and easy to reason 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 construct=
ion like CTV that services some very important uses, and then taking as muc=
h time as necessary to think about how to solve more existential problems, =
like UTXO scalability, that likely require a recursive covenant constructio=
n. </div><div><br></div><div>There doesn&#39;t have to be mutual exclusion =
in the approaches, especially when the maintenance burden of CTV seems to b=
e so low. If we end up deploying something that requires a wider variety of=
 in-script hashing, it seems likely that CTV&#39;s hash will be able to &qu=
ot;free ride&quot; on whatever more general sighash cache structure we come=
 up with.<br></div></div>

--000000000000cbdf5905d6a5e3ca--