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?
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