Hi All, Just a small remark
> lnhance is more comprehensive. but also it's so much harder to reason about > three separate op codes and what the attack surface could be. It's 4 opcodes, but ofc it's safe to ignore INTERNALKEY when it comes to unexpected interactions. We have spent basically a whole year on walking in circles with various opcode combos. We came up with a set of threshold rules that make sense as an evaluation framework: - Fine-grained introspection - State-carrying covenants - Bigint operations - New arithmetic capabilities using lookup tables These are key "ingredients" to exogenous asset protocols that are script interactible and novel bridge constructions, that might interact badly with mining decentralization. Many other proposals instantly violate some or all of them, not LNhance. To this day I haven't seen anyone come up with anything remotely scary with CTV+CSFS+PC. I would like to encourage people to take the time and try to come up with anything "nasty". BR, moonsettler Sent with Proton Mail secure email. On Thursday, November 27th, 2025 at 10:18 AM, Erik Aronesty <[email protected]> wrote: > It's been many years and there's been a lot of discussion about various > covenants > I think one of the biggest problems is everyone has to insist on their baby > is the best baby. > > op_ctv is quite literally not the best at anything. That's the whole point. > It's non-recursive, can't be used for strange or dangerous things, and can be > used to emulate a lot of other opcodes. > > It's adequate. And I don't think we want anything "better" than adequate the > first time around. lnhance is more comprehensive. but also it's so much > harder to reason about three separate op codes and what the attack surface > could be. > > I don't think it's possible to optimize a series of covenants for all > possible scenarios. Easy to make them too powerful and now nodes are doing > too much work and we're attracting the kind of network activity that nobody > wants. > > Fortunately the risk of CTV is fairly low. It's always possible to turn it > off (no new tx)... if there's a game theory issue. > > I don't think there's any particular rush, but we could lose a lot of fees > and support for miners if Bitcoin continues to do what it is doing now... > scaling almost entirely in custodial systems. That's also just not the > Bitcoin that anyone loves. > > At this point it feels like it's "perfect is the enemy of the good". > > We have an old and rather well tested pull request that is only a handful of > lines of code that everyone has scrutinized a million ways. > > I don't think we're getting that for any other covenant opcode. > > > > > > > > > > > > -- > 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/CAJowKg%2BcCoocSEYsTT3bLwte%3D-3Kbzo5k6YT--UnDwzoZPF1wQ%40mail.gmail.com. -- 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/ZDIGYB4Jcy6DGEkUGxEIBgmD0WhaNQh8X3ovu6bVwnBQ4jCQS84dkG22oLR0XJmgG0emYj9eg1mwU3I0gZtKfpovVCjlXh5FsfO0UmelT-c%3D%40protonmail.com.
