MIME-Version: 1.0
References: <G9vcdh_vztl5qzsxlbEet6nBvtC164nvV-g5e6pzUrxY4edWVroTF_h-LWnSXL0VhGQeeGpFbZA2Dm-AesIWToJ-OzdebGpqSUckw8oQseM=@protonmail.com>
In-Reply-To: <G9vcdh_vztl5qzsxlbEet6nBvtC164nvV-g5e6pzUrxY4edWVroTF_h-LWnSXL0VhGQeeGpFbZA2Dm-AesIWToJ-OzdebGpqSUckw8oQseM=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 1 May 2022 18:02:55 -0500
Message-ID: <CAGpPWDaf=ZNh3OmZBfkkfxEFb=vE=-Q_LX5bnG3s_GM2R1eivg@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a3566d05ddfb477e"
Subject: Re: [bitcoin-dev] Multiple ways to do bitcoin covenants
Precedence: list

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

I've been thinking about writing something about covenant proposals from
the viewpoint of wallet vaults specifically (mostly because that's the use
case I care most about).

CTV is basically the minimal covenant opcode you can do that doesn't have
malleability. Everything else either introduces malleability, infinite
recursion, or has interactions with other proposed opcodes that could
introduce potentially undesirable effects like those.

TXHASH+CSFS seems like on its own might enable pretty much
identical capabilities to CTV (including no malleability). But it can also
do other things (mostly because CSFS can do other things), which isn't
necessarily a bad thing, but its more stuff to be analyzed. TXHASH+CSFS in
terms of wallet vaults seems to provide no benefits over CTV as far as I
can imagine.

It seems pretty clear that anything involving OP_CAT is out for the time
being. There are so many things it can enable that it seems most people
aren't comfortable adding it at  the moment.

APO wallet vaults seem rather hacky, inefficient, and limited. Certainly
not easy to reason about. But this is somewhat a function of my limited
understanding of them. Its not clear to me if anyone is actually suggesting
that we should use APO for covenants, but it doesn't feel like the right
approach.

TLUV + IN_OUT_AMOUNT can do infinitely recursive covenants. IN_OUT_AMOUNT
wasn't very clearly specified that I know of, but its not a very robust way
of ensuring the correct amount goes where you want. If TLUV requires a
single input and a single output, IN_OUT_AMOUNT makes sense because you can
simply do opcode math to determine if the output is receiving enough coins
(and not eg being all lost as fees). Maybe it could be extended to allow
multiple outputs, but extending it to allow for multiple inputs would be
difficult and you'd probably want a completely different mechanism for
that. If you're doing any math the script itself around amounts and fees,
this doesn't work well in any scenario where multiple inputs might send to
the same address, or be combined into the same output, since each input's
script can't interact.

But since TLUV at its most basic should be able to say "remove the only
tapleaf in this tree and replace it with this other tap tree", it should be
able to do pretty arbitrary covenants. It ideally should be paired up with
something that has better control over how input amounts flow to outputs
than IN_OUT_AMOUNT allows (see the design considerations here
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>).


TLUV is built for evictions, but it seems its likely not really very good
at that, as Zman mentioned in his post about OP_EVICT
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html>
(which is a covenant opcode that can't be used for wallet vaults, tho
perhaps its characteristics can be used in a kind of TLUV2 opcode that does
evictions better, but also can add tapleaves).

OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> is
another interesting one. Also has a form that allows recursive covenants.
It also has similar awkwardness as TLUV + IN_OUT_AMOUNT around multi-input
transactions. It has the half-spend problem if two outputs are combined
that specify the same output index and script pattern. It also seems like a
rather expensive opcode to use beyond very simple covenants, since the
scripts basically has to be duplicated in the transaction specifying the
covenant and then again when the subsequent transaction is spent. Its not
very taproot friendly either: would you have to specify the entire taproot
script tree? Any similar opcode that requires specifying the exact
script(s) fundamentally can't take advantage taproot's ability to keep
scripts private until that spend path is actually used.

As far as I can tell, few of these other covenant opcodes have even been
concretely specified, let alone analyzed enough to know whether they're
worth pursuing. It seems like all but CTV (potentially TXHASH+CSFS) have
significant flaws and would need reworking in order to fix them.

I guess in short, I agree with you. Over these other ideas that have gotten
significant attention, none really seem to be of high enough quality to be
put into bitcoin in their current state.


On Thu, Apr 28, 2022 at 3:47 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> CTV and other covenant proposals, tradeoffs, and overlapping features are
> among the topics being explored recently. I had some views and questions on
> this subject.:
>
> a) Does bitcoin already have opcodes with overlapping features? Yes
>
> b) Can we have multiple ways with some overlapping features to do bitcoin
> covenants with some tradeoffs? Yes
> _
> c) What are these tradeoffs if we compare CTV, APO, TLUV and TXHASH+CSFS?
>
> I am sure about a) because it was already answered in CTV chat by Jeremy
> and sheshek. Example: CHECKSIG and CHECKSIGADD is redundant with OP_IF and
> OP_ADD
>
> Not sure if we have "consensus" on b) but I don't see anything wrong with
> it.
>
> For c) I would prefer CTV because:
>
> - Simpler
> - Blockspace effient
> - Can be used even without taproot
>
> Covering bare script, as in segwit v0, is necessary. Exposing a pubkey in
> case of an EC break will be a disaster, and vaults imply very long lived
> storage. Root CA offline certificates can often have shelf life measured in
> decades. However, NSA has issued warnings, NIST has issued guidelines, and
> executive order to prepare for the quantum shift. As a result, forcing
> everyone into a quantum-unsafe position is unsustainable.
>
> Other developers might use a different way to do bitcoin covenant for
> other reasons. Example: Russel O'Connor would prefer general OP_TXHASH
> design
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">I&#39;ve been thinking about writing something about coven=
ant proposals from the viewpoint of wallet vaults specifically (mostly beca=
use that&#39;s the use case I care most about).=C2=A0<div><br></div><div>CT=
V is basically the minimal covenant opcode you can do that doesn&#39;t have=
 malleability. Everything else either introduces malleability, infinite rec=
ursion, or has interactions=C2=A0with other proposed opcodes that could int=
roduce potentially undesirable effects like those.=C2=A0</div><div><br></di=
v><div>TXHASH+CSFS seems like on its own might enable pretty much identical=
=C2=A0capabilities to CTV (including no malleability). But it can also do o=
ther things (mostly because CSFS can do other things), which isn&#39;t nece=
ssarily a bad thing, but its more stuff to be analyzed. TXHASH+CSFS in term=
s of wallet vaults seems to provide no benefits over CTV as far as I can im=
agine.=C2=A0</div><div><br></div><div>It seems pretty clear that anything i=
nvolving OP_CAT is out for the time being. There are so many things it can =
enable that it seems most people aren&#39;t comfortable adding=C2=A0it at=
=C2=A0 the moment.=C2=A0</div><div><br></div><div>APO wallet vaults seem ra=
ther hacky, inefficient, and limited. Certainly not easy to reason about. B=
ut this is somewhat a function of my limited understanding of them. Its not=
 clear to me if anyone is actually suggesting that we should use APO for co=
venants, but it doesn&#39;t=C2=A0feel like the right approach.</div><div><b=
r></div><div>TLUV +=C2=A0<span style=3D"color:rgb(0,0,0);white-space:pre-wr=
ap">IN_OUT_AMOUNT </span>can do infinitely recursive covenants.=C2=A0<span =
style=3D"color:rgb(0,0,0);white-space:pre-wrap">IN_OUT_AMOUNT wasn&#39;t ve=
ry clearly specified that I know of, but its not a very robust way of ensur=
ing the correct amount goes where you want. If TLUV requires a single input=
 and a single output, </span><span style=3D"color:rgb(0,0,0);white-space:pr=
e-wrap">IN_OUT_AMOUNT makes sense because you can simply do opcode math to =
determine if the output is receiving enough coins (and not eg being all los=
t as fees). Maybe it could be extended to allow multiple outputs, but exten=
ding it to allow for multiple inputs would be difficult and you&#39;d proba=
bly want a completely different mechanism for that. If you&#39;re doing any=
 math the script itself around amounts and fees, this doesn&#39;t work well=
 in any scenario where multiple inputs might send to the same address, or b=
e combined into the same output, since each input&#39;s script can&#39;t in=
teract. </span></div><div><span style=3D"color:rgb(0,0,0);white-space:pre-w=
rap"><br></span></div><div><span style=3D"color:rgb(0,0,0);white-space:pre-=
wrap">But since TLUV at its most basic should be able to say &quot;remove t=
he only tapleaf in this tree and replace it with this other tap tree&quot;,=
 it should be able to do pretty arbitrary covenants. It ideally should be p=
aired up with something that has better control over how input amounts flow=
 to outputs than </span><span style=3D"color:rgb(0,0,0);white-space:pre-wra=
p">IN_OUT_AMOUNT allows (see the design considerations <a href=3D"https://g=
ithub.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constra=
indestination.md" target=3D"_blank">here</a>). </span></div><div><br></div>=
<div>TLUV is built for evictions, but it seems its likely not really very g=
ood at that, as Zman mentioned in <a href=3D"https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2022-February/019926.html" target=3D"_blank">his =
post about OP_EVICT</a> (which is a covenant opcode that can&#39;t be used =
for wallet vaults,=C2=A0tho perhaps its characteristics can be used in a ki=
nd of TLUV2 opcode that does evictions better, but also can add tapleaves).=
</div><div><br></div><div><a href=3D"https://fc16.ifca.ai/bitcoin/papers/ME=
S16.pdf" target=3D"_blank">OP_CHECKOUTPUTVERIFY</a>=C2=A0is another interes=
ting one. Also has a form that allows recursive covenants. It also has simi=
lar awkwardness as TLUV + IN_OUT_AMOUNT around multi-input transactions. It=
 has the half-spend problem if two outputs are combined that specify the sa=
me output index and script pattern. It also seems like a rather expensive o=
pcode to use beyond very simple covenants, since the scripts basically has =
to be duplicated in the transaction specifying the covenant and then again =
when the subsequent transaction is spent. Its not very taproot friendly eit=
her: would you have to specify the entire taproot script tree? Any similar =
opcode that requires specifying the exact script(s) fundamentally can&#39;t=
 take advantage taproot&#39;s=C2=A0ability to keep scripts private until th=
at spend path is actually used.</div><div><br></div><div>As far as I can te=
ll, few of these other covenant opcodes have even been concretely specified=
, let alone analyzed enough to know whether they&#39;re worth pursuing. It =
seems like all but CTV (potentially TXHASH+CSFS) have significant flaws and=
 would need reworking in order to fix them.=C2=A0</div><div><br></div><div>=
I guess in short, I agree with you. Over these other ideas that have gotten=
 significant attention, none really seem to be of high enough quality to be=
 put into bitcoin in their current state.=C2=A0</div><div><br></div><div><b=
r></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, Apr 28, 2022 at 3:47 AM alicexbt via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:ari=
al;font-size:14px"><span>CTV and other covenant proposals, tradeoffs, and o=
verlapping features are among the topics being explored recently. I had som=
e views and questions on this subject.:</span><div><br></div><div><span>a) =
Does bitcoin already have opcodes with overlapping features? Yes</span></di=
v><div><br></div><div><span>b) Can we have multiple ways with some overlapp=
ing features to do bitcoin covenants with some tradeoffs? Yes</span></div><=
div><span>_</span></div><div><span>c) What are these tradeoffs if we compar=
e CTV, APO, TLUV and TXHASH+CSFS?</span></div><div><br></div><div><span>I a=
m sure about a) because it was already answered in CTV chat by Jeremy and s=
heshek. Example: CHECKSIG and CHECKSIGADD is redundant with OP_IF and OP_AD=
D</span></div><div><br></div><div><span>Not sure if we have &quot;consensus=
&quot; on b) but I don&#39;t see anything wrong with it.</span></div><div><=
br></div><div><span>For c) I would prefer CTV because:</span></div><div><br=
></div><div><span>- Simpler</span></div><div><span>- Blockspace effient</sp=
an></div><div><span>- Can be used even without taproot</span></div><div><br=
></div><div><span>Covering bare script, as in segwit v0, is necessary. Expo=
sing a pubkey in case of an EC break will be a disaster, and vaults imply v=
ery long lived storage. Root CA offline certificates can often have shelf l=
ife measured in decades. However, NSA has issued warnings, NIST has issued =
guidelines, and executive order to prepare for the quantum shift. As a resu=
lt, forcing everyone into a quantum-unsafe position is unsustainable.</span=
></div><div><br></div><div><span>Other developers might use a different way=
 to do bitcoin covenant for other reasons. Example: Russel O&#39;Connor wou=
ld prefer general OP_TXHASH design</span></div><span></span><br></div><div =
style=3D"font-family:arial;font-size:14px">/dev/fd0</div><div style=3D"font=
-family:arial;font-size:14px"><br></div>
<div style=3D"font-family:arial;font-size:14px">
    <div>

            </div>

            <div>
        Sent with <a href=3D"https://protonmail.com/" rel=3D"noopener noref=
errer" target=3D"_blank">ProtonMail</a> secure email.
    </div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000a3566d05ddfb477e--