Hi James, > 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? See my novel answer to AJ that by extending bitcoin script, I think you might *actually* diluting the UTXO model as you can now on cross-inspect the status of an outpoint. This might amplify tx-withhold style risk for bitcoin contracting protocols, e.g vaults. > 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). Live != Deployed use-cases built on top of those advanced introspection opcodes. I've not verified this by myself, though from what is available from public data L-BTC is <= to LN today in terms of locked coins. In terms of decentralization, a federated side-chain is not even like a network of payment channels, where everyone can join by confirming a 2-of-2 in the chain. So have skilled dev really try do "wrong things" with L-BTC and all those shiny introspection opcodes ? I'm not sure, and please accept my skepticism here. > 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. No -- Apologies to tell you that science / engineering != politics. Somehow, if one has taste and familiarity with all postmodernism sociology, there is well one domain where it completely failed to demonstrate that things are following a "political process", this is indeed the domain of science. In science, mathematical or physical truth always prevails, no matter what. Don't get me wrong -- This doesn't mean I cannot share the opinion that current consensus changes process is a complete conoundrum. Sadly it might have devolved in the view of numerous segments of the Bitcoin ecosystem that what matters w.r.t consensus build-up is who is sitting on a bunch of surreanous github repository permissions, and not necessarily if the consensus change is benefitful in an objective fashion for bitcoin, not even if such _consensus change_ might be required for the long-term flourishing of bitcoin (at least fixing the technical debt). There is difference in saying what makes you socially popular to be vetted with empty github permissions and let you vegetate on them by a weak social consensus and there is a difference in saying unpopular truth to nurture real changes on the long-term. I won't open the conversation more on that subject. Now, back to the more technical analysis of covenant, personally my position is still the same than it was discussed on Bitcoin Core #28550. The communication tone was rude, for sure, though I still share the same belief we shouldn't be careful in designing contracting primitives and be completely $YOLO if said primitives works well for a second-layer. On concerning CheckTemplateVerify itself, which is itself simpler than any other proposed soft-forks due to the non-malleable templating, as I said 18 months ago I'm still open in my free time to review/test a CTV-based vault (https://github.com/jamesob/simple-ctv-vault), the same way I did for Eltoo-based LN channels in the past. This is one thing to come with a proof-of-concept working on a single workstation, this is another thing to have tested it under real operational guidelines, where dynamic fees and keys ceremonies have to be deal with. I don't think CTV is altering the UTXO model significantly, though pleasure to be proven wrong here. On the other hand CTV is bringing this idea of immutability in a chain of transactions, that we cannot do currently with sigs-based covenant. That immutability in theory has consequential value for anyone building cold wallet or vault, that is clear as once the funding utxo is confirmed, the UTXO signing keys leaks are void. Now, I might be the last guy in the ecosystem to think that CTV is not the promised silver-bullet by its author all over the world to design and deploy vaults. Fine. > 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. I do not wish to be overly pessimitic, though I think whatever "just-drop-a-new script-interpreter" approach is just the wrong design approach, if we do not go to fix first all the dynamic fees issues grieving all the contracting protocols and bitcoin second-layers. Side-note: if you're used with playing with your compiler to target exotic ISAs, one could build the equivalent for any Lisp interpreter where there is an IR and in function of the target you compile to current supported bitcoin opcodes, disabling interpreter syntax that are not (currently) supported or that cannot be translated. I think this would be already a formal verification gain for any smart-contract toolchain using it, even if it's a subset. > 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. I agree that LoC is a decent heuristic for marginal risk. Best, Antoine OTS hash: 7f00760799b4defd9fe551673a7926c01704274e522d44f3dc8e701b320243de Le samedi 8 mars 2025 à 16:39:34 UTC, James O'Beirne a écrit : > 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/5610731e-b4a3-448d-bf4b-508739d51198n%40googlegroups.com.