From: Paul Sztorc <truthcoin@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Date: Mon, 9 Jun 2025 19:02:44 -0700 (PDT) [thread overview]
Message-ID: <7db9795a-53ff-4a1e-973e-d6be029d9022n@googlegroups.com> (raw)
In-Reply-To: <n4MR-H83t3x3B5yI8tjdTXR21smp_Ur7fRpqk_4EOc_im_zu0-9GlqxC1wl-gEzS__TdJNrf6XsV4XXOzxWn4kpdUocR3Xp8d6Uwo1m4ILw=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 10891 bytes --]
> the urgency with a six months deadline is nothing short of reckless.
But why would 6 months be considered "urgent"?
I think the tiniest amount of clarity would help. I propose a new table
(like the covenants support table), where we each self-sort ourselves into
whichever category describes us BEST:
1) Those who believe ...that each soft fork should take 5+ years (like
CTV). ...that we can only activate one soft fork at a time. ...that we must
debate and "agree" upon which one, to activate. ...that soft forks are a
dramatic event, different from other pull requests. ...that we need
"consensus" among humans to activate a soft fork. [Etc, etc]
2) Those who would prefer Bitcoin development to revert, more back toward
the way things were, pre-SegWit drama. In other words: we can activate
multiple soft forks at once ; soft forks do not require "agreement" among
humans -- they just need to meet the same quality threshold as other
pull-requests ; we should merge any pull-request, if it is a good idea
(regardless of if it is a soft fork or not -- the soft fork part, only
affects when it is safe for users to rely on the feature). The [OP NOP / OP
Success]-style forks, are inherently very safe, ignore-able, and
reversible. In theory, we could activate 15 of these in the next release,
and then later change our mind, and "deactivate" any (or all) of these (by
banning that opcode from ever being spent to/from again). In that
hypothetical scenario (very different from ours today), we would
preemptively explain (to users), that all "new opcodes" (less than a year
old), are "experimental", and may be "deactivated" at any time -- each user
could decide for themselves if they want to take this risk (during the
first 12 months).
3) Those unwilling to clarify their opinion.
If people think "2 soft forks per 10 years" is the right way to go, then
they should stand behind that point of view.
People seem to want it both ways -- on one hand, reluctant to stick their
neck out for any particular soft fork; but, on the other hand, too ashamed
to admit that they are quietly handcuffing the Bitcoin project to the "5+
years per softfork", bike-shedding timeline.
Cheers,
Paul
P.S. I have never used google groups before so I hope this email goes out
correctly.
On Monday, June 9, 2025 at 5:17:54 PM UTC-4 Antoine Poinsot wrote:
> James, cosigners,
>
> I am sympathetic to the idea of a CTV+CSFS soft fork, mainly for its
> flagship use case: LN-Symmetry.
>
> However i think it is premature to call for a "final review and
> activation" of these opcodes when
> there is still:
> - disagreement between Bitcoin protocol developers/researchers that it is
> the way to go for enabling
> more expressive scripting capabilities in Bitcoin[^0];
> - disagreement between Bitcoin developers on how the functionality of at
> least one of the proposed
> opcodes should be achieved[^1];
> - no review after three months, from any of the champions or signers of
> this letter, on the PR for
> integrating one of the two proposed opcodes to the test network[^2].
>
> The flagship use case of the proposal has also not been properly
> demonstrated. As a point of
> comparison Greg Sanders provided motivation for `ANYPREVOUT`, a soft fork
> that no one even called
> to be "finally reviewed and activated", by publishing a detailed proof of
> concept of LN-Symmetry
> (with full specification as a BOLT draft + an implementation in one of the
> major Lightning clients).
>
> A comprehensive exploration gives confidence a use case is actually
> realistic in practice. Of course
> it's not necessary to go to such lengths just to demonstrate it to be
> *possible*, but it is
> reasonable to expect a champion to have something to show if they are
> calling for changing Bitcoin.
> Fortunately i hear some have taken upon themselves to further explore
> LN-Symmetry and multiparty
> channels using CTV+CSFS, which could provide tangible motivation for the
> soft fork. Let's see what
> they come up with.
>
> Finally, it seems the post contains a built-in assumption that Bitcoin
> Core contributors are
> detached from the research in more expressive scripting capabilities. It
> is incorrect. A number of
> individuals have been involved both with Bitcoin Core development and
> Bitcoin protocol research,
> with substantial contributions in both areas.
>
> Therefore it seems the stalling state of the CTV+CSFS proposal is not due
> to apathy as this open
> letter would lead to believe, but controversy on the content of the
> proposal among Bitcoin protocol
> developers as well as a lack of involvement from the part of champions in
> reaching consensus.
>
> In these conditions calling for an impending change to Bitcoin's consensus
> rules seems unadvisable,
> and the urgency with a six months deadline is nothing short of reckless.
>
> I remain confident we can make progress toward enabling more expressive
> scripting capabilities in
> Bitcoin. The path forward is by building consensus on the basis of strong
> technical arguments, and
> the politics of pushing for the premature activation of a consensus change
> are working against it.
>
> Best,
> Antoine Poinsot
>
>
> [^0]:
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/14
> https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4...@mattcorallo.com
> <https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4-ac51-b881d8df9f01@mattcorallo.com>
> [^1]:
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/58
> [^2]: https://github.com/bitcoin-inquisition/bitcoin/pull/72
> [^3]: https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
>
>
> On Monday, June 9th, 2025 at 7:54 AM, James O'Beirne <james....@gmail•com>
> wrote:
>
> > Good morning,
> >
> > A letter has been published advocating for the final review and
> > activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK
> > (BIP-348).
> >
> > The full text of the letter can be found at https://ctv-csfs.com. It is
> > reproduced below.
> >
> > ---
> >
> > To the technical bitcoin community,
> >
> > We believe that the best next step for bitcoin would be to activate
> > OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK (CSFS,
> > BIP-348). These opcodes enable functionality for a broad set of uses
> > that will allow bitcoin to preserve and expand its role as a scarce,
> > censorship-resistant store of value.
> >
> > While there are a few promising proposals to improve bitcoin at the
> > consensus layer which may someday be deployed, we believe that CTV and
> > CSFS are uniquely well reviewed, simple, and have been proven to be both
> > safe and widely demanded.
> >
> > CTV was first formalized in BIP-119 over 5 years ago. Despite many
> > attempts at refinement or replacement, it has remained the most widely
> > preferred method for enforcing pregenerated transaction sequences using
> > consensus. It unlocks valuable functionality for scaling solutions,
> > vaults, congestion control, non-custodial mining, discreet log
> > contracts, and more.
> >
> > CSFS is a primitive opcode that has been deployed to Blockstream’s
> > Elements for at least 8 years. It represents no significant
> > computational burden over bitcoin’s most often used opcode, OP_CHECKSIG.
> > It can be combined with CTV to implement ln-symmetry, a longstanding
> > improvement to Lightning. It also unlocks a variety of other use cases.
> >
> > We respectfully ask Bitcoin Core contributors to prioritize the review
> > and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or
> > similar) within the next six months. We believe this timeline allows for
> > rigorous final review and activation planning.
> >
> > This request isn't meant to suggest that these contributors dictate the
> > consensus process, but rather it is an acknowledgement that before these
> > opcodes can be activated, they must be implemented in the most widely
> > used bitcoin client.
> >
> > As application and protocol developers, we are convinced of the
> > significant benefits that these changes would bring to end users of
> > bitcoin – even if only considering their use for layer 1 security and
> > layer 2 scaling solutions. We are optimistic that given the limited size
> > and scope of these changes in both concept and implementation, they
> > represent a realistic next step in the continuing and important work of
> > preserving bitcoin's unique promise.
> >
> > Signed,
> >
> > Abdel (Starkware)
> > Andrew Poelstra (@apoelstra)
> > Ben Carman (@benthecarman)
> > Ben Kaufman (@ben-kaufman)
> > Brandon Black (@reardencode)
> > Brian Langel (for Five Bells)
> > Buck Perley (@puckberley)
> > Calle (Cashu)
> > Calvin Kim (@kcalvinalvin)
> > Chun Wang (f2pool)
> > Christian Decker (@cdecker)
> > Coinjoined Chris (Bitsurance.eu)
> > Evan Kaloudis (for Zeus)
> > fiatjaf (@fiatjaf)
> > Floppy (@1440000bytes)
> > Gary Krause (@average-gary)
> > Harsha Goli (@arshbot)
> > Hunter Beast (@cryptoquick)
> > Jad Mubaslat (@champbronc2)
> > James O’Beirne (@jamesob)
> > Jameson Lopp (@jlopp)
> > Johan Halseth (@halseth)
> > Luke Childs (@lukechilds)
> > Matt Black (for Atomic Finance)
> > Michael Tidwell (@miketwenty1)
> > Nick Hansen (for Luxor Mining)
> > Nitesh (@nitesh_btc)
> > nvk (@nvk)
> > Owen Kemeys (for Foundation)
> > Paul Sztorc (@psztorc)
> > Portland.HODL (for MARA Pool)
> > Rijndael (@rot13maxi)
> > Rob Hamilton (@rob1ham)
> > Robin Linus (@RobinLinus)
> > Sanket Kanjalkar (@sanket1729)
> > Sean Ryan (Anchorage)
> > Seth for Privacy (for Cake Wallet)
> > Simanta Gautam (Alpen Labs)
> > Steven Roose (@stevenroose)
> > stutxo (@stutxo)
> > Talip (@otaliptus)
> > mononaut (@mononautical)
> > vnprc (@vnprc)
> >
> >
> > --
> > 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+...@googlegroups•com.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.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/7db9795a-53ff-4a1e-973e-d6be029d9022n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 14401 bytes --]
next prev parent reply other threads:[~2025-06-10 2:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 11:40 James O'Beirne
2025-06-09 12:51 ` Michael Folkson
2025-06-09 14:41 ` James O'Beirne
2025-06-09 15:56 ` Michael Folkson
2025-06-09 13:51 ` Matt Corallo
2025-06-09 14:43 ` James O'Beirne
2025-06-09 17:51 ` Matt Corallo
2025-06-09 19:27 ` /dev /fd0
2025-06-09 21:12 ` Matt Corallo
2025-06-09 18:55 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 2:02 ` Paul Sztorc [this message]
2025-06-09 23:02 ` Andrew Poelstra
2025-06-10 2:08 ` David A. Harding
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=7db9795a-53ff-4a1e-973e-d6be029d9022n@googlegroups.com \
--to=truthcoin@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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