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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n%40googlegroups.com.
