* [bitcoindev] op_ctv still has no technical objections
@ 2025-11-27 7:43 Erik Aronesty
2025-11-28 2:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Erik Aronesty @ 2025-11-27 7:43 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJowKg%2BcCoocSEYsTT3bLwte%3D-3Kbzo5k6YT--UnDwzoZPF1wQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2985 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* [bitcoindev] Re: op_ctv still has no technical objections
2025-11-27 7:43 [bitcoindev] op_ctv still has no technical objections Erik Aronesty
@ 2025-11-28 2:04 ` 'conduition' via Bitcoin Development Mailing List
2025-11-29 23:08 ` [bitcoindev] " /dev /fd0
2025-12-19 14:58 ` 'moonsettler' via Bitcoin Development Mailing List
2 siblings, 0 replies; 5+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2025-11-28 2:04 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2607 bytes --]
As someone who has had a merely passive interest in covenants tech, I can
confidently say that OP_CTV is probably the only covenants proposal whose
effects I can confidently say I fully grasp. It's also easy to explain to
others. Not saying i'm not in favor of more complex multi-pronged upgrades
like LNHANCE, just saying I don't fully understand their opcode interplay
enough to say yay/nay. Which is maybe an under-represented argument in
favor of plain OP_CTV.
regards,
conduition
On Thursday, November 27, 2025 at 1:18:03 AM UTC-8 Erik Aronesty 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2914ad6f-7e1a-42b6-9c25-87ac48c63228n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3790 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] op_ctv still has no technical objections
2025-11-27 7:43 [bitcoindev] op_ctv still has no technical objections Erik Aronesty
2025-11-28 2:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
@ 2025-11-29 23:08 ` /dev /fd0
2025-12-18 19:01 ` Erik Aronesty
2025-12-19 14:58 ` 'moonsettler' via Bitcoin Development Mailing List
2 siblings, 1 reply; 5+ messages in thread
From: /dev /fd0 @ 2025-11-29 23:08 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]
Hi Erik,
We can organize a meeting to discuss the activation parameters and build an
activation client. If enough economic nodes and miners run the activation
client it will be activated with no further politics or drama.
#ctv-csfs-activation IRC channel can be used for the meeting.
/dev/fd0
floppy disk guy
On Thu, Nov 27, 2025 at 2:47 PM Erik Aronesty <erik@q32.com> 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 bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAJowKg%2BcCoocSEYsTT3bLwte%3D-3Kbzo5k6YT--UnDwzoZPF1wQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAJowKg%2BcCoocSEYsTT3bLwte%3D-3Kbzo5k6YT--UnDwzoZPF1wQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALiT-ZrgNdMVs7mAWRhrXEqkyxXAdjE-gwjZfpv%3D2arzcSFopA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4434 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] op_ctv still has no technical objections
2025-11-29 23:08 ` [bitcoindev] " /dev /fd0
@ 2025-12-18 19:01 ` Erik Aronesty
0 siblings, 0 replies; 5+ messages in thread
From: Erik Aronesty @ 2025-12-18 19:01 UTC (permalink / raw)
To: /dev /fd0; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3439 bytes --]
Hello, out of this meeting it was generally agreed that it's appropriate to
propose a conservative activation mechanism, using BIP 9, with a long
activation window and high miner threshold.
Question: Do we need a new BIP, or should we update BIP119 with the new
activation parameters?
On Sat, Nov 29, 2025 at 3:08 PM /dev /fd0 <alicexbtong@gmail.com> wrote:
> Hi Erik,
>
> We can organize a meeting to discuss the activation parameters and build
> an activation client. If enough economic nodes and miners run the
> activation client it will be activated with no further politics or drama.
>
> #ctv-csfs-activation IRC channel can be used for the meeting.
>
> /dev/fd0
> floppy disk guy
>
> On Thu, Nov 27, 2025 at 2:47 PM Erik Aronesty <erik@q32.com> 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 bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAJowKg%2BcCoocSEYsTT3bLwte%3D-3Kbzo5k6YT--UnDwzoZPF1wQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAJowKg%2BcCoocSEYsTT3bLwte%3D-3Kbzo5k6YT--UnDwzoZPF1wQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/CAJowKg%2BvDs3qb9uEvQpcYsDjtVnS34aUr5_zbZqPtnE8TXEuuw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5119 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] op_ctv still has no technical objections
2025-11-27 7:43 [bitcoindev] op_ctv still has no technical objections Erik Aronesty
2025-11-28 2:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-11-29 23:08 ` [bitcoindev] " /dev /fd0
@ 2025-12-19 14:58 ` 'moonsettler' via Bitcoin Development Mailing List
2 siblings, 0 replies; 5+ messages in thread
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-12-19 14:58 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Development Mailing List
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 <erik@q32.com> 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 bitcoindev+unsubscribe@googlegroups.com.
> 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ZDIGYB4Jcy6DGEkUGxEIBgmD0WhaNQh8X3ovu6bVwnBQ4jCQS84dkG22oLR0XJmgG0emYj9eg1mwU3I0gZtKfpovVCjlXh5FsfO0UmelT-c%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-12-19 15:10 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-27 7:43 [bitcoindev] op_ctv still has no technical objections Erik Aronesty
2025-11-28 2:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-11-29 23:08 ` [bitcoindev] " /dev /fd0
2025-12-18 19:01 ` Erik Aronesty
2025-12-19 14:58 ` 'moonsettler' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox