Re: [bitcoindev] "Recursive covenant" with CTV and CSFS

[Anthony Towns <aj@erisian.com.au>]

On Tue, Mar 04, 2025 at 10:14:59PM -0800, Olaoluwa Osuntokun wrote:
> > Since BIP 119's motivation is entirely concerned with its concept of
> > covenants and avoiding what it calls recursive covenants
> If we look at the motivation section of BIP 119, we find this sentence:
> > This BIP introduces a simple covenant called a *template* which enables a
> > limited set of highly valuable use cases without significant risk. BIP-119
> > templates allow for non-recursive fully-enumerated covenants with no
> > dynamic state.
> You appear to have latched onto the "non-recursive" aspect, ignoring the
> subsequent qualifiers of "fully-enumerated" and "with no dynamic state".
>
> The example that you've come up with to "directly undermine" the claimed
> motivations of BIP 119 is still fully enumerated (the sole state is declared
> up front), and doesn't contain dynamic state (I can't spend the contract on
> chain and do something like swap in another hash H, or signature S).

The reason "fully-enumerated" provides any "safety" is that it occurs
when the scriptPubKey is chosen -- without the availability of CSFS,
you either include the CTV hash in the scriptPubKey or the use of CTV
provides no protection at all.

My example does not include the CTV hash in the scriptPubKey, which is
what allows the CTV hash to then commit to the scriptPubKey, which in turn
allows for the unbounded recursion.

If you instead did not delete the CSFS private key would allow you to
swap in another hash H or signature S in future. That would perhaps
allow designing an unbounded state machine where a master key can add
new states in future. It's not immediately obvious to me if there's
anything interesting that can be done with that.

In any event, if there is some weird subset of use cases that are somehow
both scary and still prevented even by the combination of CTV and CSFS
the BIP should be updated to document that.

> > For me, the bllsh/simplicity approach makes more sense as a design
> > approach for the long term
> Simplicity certainly has some brilliant devs working on it, but after all
> these years it still seems to be struggling to exit research mode with some
> "killer apps" on Liquid.

https://github.com/ElementsProject/elements/pull/1427 suggests
Simplicity's potentially going live on Liquid any day now.

> The current Overton Window appears to be focused on a
> small (LoC wise) package to enable a greater degree of permissionless
> innovation on Bitcoin, while leaving the research landscape open for more
> dramatic overhauls (bllsh/Simplicity) in the future.

The concept of an "Overton window" is a political one, used for when
there has been successful political pressure to exclude some subjects
from discussion for reasons other than their underlying merits. That's
not a good idea if you want to maintain high quality, and it's probably
not compatible at all with a project that aims to be decentralised in
any meaningful way.

Certainly a small change (though LoC is a bad measure of that -- how
many LoC does it take to drop the 21M limit, or to drop the subsidy from
3.125 BTC to 0 BTC?) is better than a large change all else being equal;
but all else isn't equal: different changes enable different feature
sets. The question you should be asking is whether we're getting useful
feature sets from the small changes being proposed.

If you want "permissionless innovation", then many small incremental
consensus changes are not a good way of doing it -- as that involves
asking the global network of Bitcoin users for permission for each
individual change.

Cheers,
aj

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z8tes4tXo53_DRpU%40erisian.com.au.