From: "/dev /fd0" <alicexbtong@gmail.com>
To: Erik Aronesty <erik@q32.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] op_ctv still has no technical objections
Date: Sun, 30 Nov 2025 04:38:27 +0530 [thread overview]
Message-ID: <CALiT-ZrgNdMVs7mAWRhrXEqkyxXAdjE-gwjZfpv=2arzcSFopA@mail.gmail.com> (raw)
In-Reply-To: <CAJowKg+cCoocSEYsTT3bLwte=-3Kbzo5k6YT--UnDwzoZPF1wQ@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2025-11-29 23:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 7:43 Erik Aronesty
2025-11-28 2:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-11-29 23:08 ` /dev /fd0 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALiT-ZrgNdMVs7mAWRhrXEqkyxXAdjE-gwjZfpv=2arzcSFopA@mail.gmail.com' \
--to=alicexbtong@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=erik@q32.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox