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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z8tes4tXo53_DRpU%40erisian.com.au.
