* Re: [bitcoin-dev] Multiple ways to do bitcoin covenants
2022-04-28 8:11 [bitcoin-dev] Multiple ways to do bitcoin covenants alicexbt
@ 2022-05-01 23:02 ` Billy Tetrud
0 siblings, 0 replies; 2+ messages in thread
From: Billy Tetrud @ 2022-05-01 23:02 UTC (permalink / raw)
To: alicexbt, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6114 bytes --]
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 #2: Type: text/html, Size: 8151 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread