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

[James O'Beirne <james.obeirne@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3407 bytes --]

On Friday, March 7, 2025 at 4:26:36 PM UTC-5 Anthony Towns wrote:

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.


I'm not sure what your point here is - that we can do stupid things with 
CTV + CSFS? That's universally true in bitcoin; I can have an "unbounded 
state machine" by sending myself the same UTXO back and forth indefinitely 
with CHECKSIG.

As with everything in bitcoin, the chain is insulated from stupidity like 
that by fees, the UTXO model, and block cadence, so what's the problem?
 

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


Probably worth noting that CSFS and many advanced introspection opcodes 
(which allow synthesizing CTV) have been live for almost *four years now* 
on Liquid 
(https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-functionality).
 

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.


Sorry to tell you, but given that changing consensus requires soliciting 
buy-in from a wide variety of people across the Bitcoin ecosystem with 
varying levels of technical ability, it is inherently a political process.

Beyond that, "Overton window" is an appropriate device in the sense that 
roasbeef is using it because the more substantial a proposed change is, the 
more time is needed by the technical ecosystem to digest it, both in terms 
of tooling and safety analysis. Introducing an entirely new script 
interpreter on the basis of a Lisp (or combinator calculus, or whatever 
Simplicity's claim is) is indeed far outside of that "Overton" window - 
much farther than tacking on what is essentially just a new SIGHASH mode to 
the existing interpreter.
 

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.


Let's not be petty here - it's clear he's talking about LoC within the 
script interpreter, which is a different context than the codebase as a 
whole. Within the context of the interpreter, LoC is indeed a decent 
heuristic for marginal risk. Of course, nobody's saying it's perfect.

James

-- 
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/45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4497 bytes --]