[prev in list] [next in list] [prev in thread] [next in thread]
List: bitcoin-dev
Subject: Re: [bitcoin-dev] Multiple ways to do bitcoin covenants
From: Billy Tetrud via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date: 2022-05-01 23:02:55
Message-ID: CAGpPWDaf=ZNh3OmZBfkkfxEFb=vE=-Q_LX5bnG3s_GM2R1eivg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
>
[Attachment #5 (text/html)]
<div dir="ltr">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). <div><br></div><div>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. \
</div><div><br></div><div>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. \
</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>TLUV + <span \
style="color:rgb(0,0,0);white-space:pre-wrap">IN_OUT_AMOUNT </span>can do infinitely \
recursive covenants. <span \
style="color:rgb(0,0,0);white-space:pre-wrap">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, \
</span><span style="color:rgb(0,0,0);white-space:pre-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 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. \
</span></div><div><span \
style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span \
style="color:rgb(0,0,0);white-space:pre-wrap">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 </span><span \
style="color:rgb(0,0,0);white-space:pre-wrap">IN_OUT_AMOUNT allows (see the design \
considerations <a href="https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md" \
target="_blank">here</a>). </span></div><div><br></div><div>TLUV is built for \
evictions, but it seems its likely not really very good at that, as Zman mentioned in \
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html" \
target="_blank">his post about OP_EVICT</a> (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).</div><div><br></div><div><a \
href="https://fc16.ifca.ai/bitcoin/papers/MES16.pdf" \
target="_blank">OP_CHECKOUTPUTVERIFY</a> 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.</div><div><br></div><div>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. \
</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. \
</div><div><br></div><div><br></div><div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 28, 2022 at 3:47 AM \
alicexbt via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" \
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="font-family:arial;font-size:14px"><span>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.:</span><div><br></div><div><span>a) \
Does bitcoin already have opcodes with overlapping features? \
Yes</span></div><div><br></div><div><span>b) Can we have multiple ways with some \
overlapping features to do bitcoin covenants with some tradeoffs? \
Yes</span></div><div><span>_</span></div><div><span>c) What are these tradeoffs if we \
compare CTV, APO, TLUV and TXHASH+CSFS?</span></div><div><br></div><div><span>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</span></div><div><br></div><div><span>Not sure if we have \
"consensus" on b) but I don'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</span></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. 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.</span></div><div><br></div><div><span>Other developers might use a \
different way to do bitcoin covenant for other reasons. Example: Russel O'Connor \
would prefer general OP_TXHASH design</span></div><span></span><br></div><div \
style="font-family:arial;font-size:14px">/dev/fd0</div><div \
style="font-family:arial;font-size:14px"><br></div> <div \
style="font-family:arial;font-size:14px"> <div>
</div>
<div>
Sent with <a href="https://protonmail.com/" rel="noopener noreferrer" \
target="_blank">ProtonMail</a> secure email. </div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" \
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> <a \
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" \
rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic