path: root/ec/497cc1ee932702695c6b6397c0be1b31238714

Delivery-date: Mon, 09 Jun 2025 19:06:37 -0700
Received: from mail-yw1-f189.google.com ([209.85.128.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDCO7XPNUQFBBIVGT3BAMGQEOKYGOQQ@googlegroups.com>)
	id 1uOoNo-0003RI-0S
	for bitcoindev@gnusha.org; Mon, 09 Jun 2025 19:06:37 -0700
Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-7111ff9f2d4sf19541307b3.0
        for <bitcoindev@gnusha.org>; Mon, 09 Jun 2025 19:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749521190; x=1750125990; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=f/HF8c/E4CwvCVFAJi+M7PAdBzHSWUE3ap2A0JvmoT4=;
        b=uoMtNgi9310IDiWsDJcFK4zc7r45NxD0egTbgBr1fVeo5LzFvzLP/YQZpqsHMS/zKV
         5XaKLs/jERiuErIGnvJZ6QI4gb/uOx2VdhLOdRxt2GGk9rDpA2cLknYBiLDaoLpQnhhk
         fXp7hBz69YaBKvgnexMAIgrUPO76bRzWPD8/BO4pHN62P7Nigq31iya16/Ftays6bZEd
         H3usgQvNvlTu6FsVQXHy/CokQwHmavkEDGZBKFMezs99J9exKFUaRc/OaURJOhYYbFh3
         9l3bZU94qVU7z7NDjw09IM0XWhmCrcMTPFZQVxdkJIC5BSlSWF9zAfmtJSGnFowBaKPy
         37Eg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749521190; x=1750125990; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=f/HF8c/E4CwvCVFAJi+M7PAdBzHSWUE3ap2A0JvmoT4=;
        b=knmTbVOtfHeYYOr3mwK/GXufp1Qqn3ML4b5r2jqW2t+8H4sVFKexq4CFK5x5AIleNu
         dVWfE5deKkVX1uXXhzlEn44rc4lHKeSssd9YxW6RQRWCnzAL4GJwelCPuwtfm7cZ2GyP
         5UZW+LgJe24KEfyucJY0bApiaORerK4cxgAtyKxZ2vk6wu6yEhxBCElfjnbj94UC7LMm
         pfl+swTTiOQI2T9rWHg46cW1kyTy/lchi7f82BkTKfWzwjSu8Kv2BUJ29onlh5JrQOTb
         8wzQWuFpYm6iRagsbYZCLcaSK4aNwYG/4ZCd44hJ5m4bI2co8cvmrfK0P09VeKdgrFbS
         EgQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749521190; x=1750125990;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=f/HF8c/E4CwvCVFAJi+M7PAdBzHSWUE3ap2A0JvmoT4=;
        b=L8WzlVFvq5InqdxlfRTEI25ro9BBI8iSkzJgQ7eXOA19YcDbdKBrmBb4KPIEvbGk55
         c6pPFQyvbv1RvBWy0BtyiT6YsHvsI5323o/Slh/BvZChHd7RWgyoqwNKip3RQtzj9Jvj
         kUNiClLs3AFAuNNl/hI0CZTMCVJAn1UdAJR74UOdnuOd5/K2voHVOEBoiTxND3KJ3bs8
         DtanMhvc8k+fuq1XSWrQ6YKxlw/YNdTU/fSp1wy/aZFBPxC9o/iRyIemAumTyl204kqR
         YY7JIyLlalu37DYO/zcY3JBjv/B07Swax2jX3c3IsWoxellLoQPxfIgoN5B1wSjgocBd
         31xA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWD8H0p1KX5pdI+xtWrrhCJXCC2ANVzJIiBZ6lKOHV74yeIB8w3QhewAG9ha2t45Qkx+SzjixOuAx1U@gnusha.org
X-Gm-Message-State: AOJu0YxlBqarwVPB34vJmsL7eKPihRdX64b26F8P84G16A7dg+aHR+xz
	PIWzRUFQd1U5/mfrQevADohOFR/n3Z95iqhUZagi0msGUXDajoyoJCiK
X-Google-Smtp-Source: AGHT+IENJZ3HfJLatIBiHyGbJCy2gyIme25hvEx/GExP1a5eUDMZNUocch3CXibPnY/xuICm+k+okA==
X-Received: by 2002:a05:6902:4906:b0:e81:718c:e36a with SMTP id 3f1490d57ef6-e81a2350166mr21187159276.47.1749521190019;
        Mon, 09 Jun 2025 19:06:30 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZefPJtk1e0FJHgPZOKSyfwMXdAxDokaYPhKbw3n2+kk9A==
Received: by 2002:a25:d386:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e8188a2baf7ls5041447276.2.-pod-prod-00-us;
 Mon, 09 Jun 2025 19:06:26 -0700 (PDT)
X-Received: by 2002:a05:690c:8f05:b0:70d:f09a:bb4d with SMTP id 00721157ae682-711336833a0mr20443317b3.0.1749521186324;
        Mon, 09 Jun 2025 19:06:26 -0700 (PDT)
Received: by 2002:a05:690c:fc7:b0:710:fccf:6901 with SMTP id 00721157ae682-710fccf6a41ms7b3;
        Mon, 9 Jun 2025 19:02:46 -0700 (PDT)
X-Received: by 2002:a05:690c:6a11:b0:70d:fd6f:b151 with SMTP id 00721157ae682-711338b2837mr25902017b3.11.1749520965200;
        Mon, 09 Jun 2025 19:02:45 -0700 (PDT)
Date: Mon, 9 Jun 2025 19:02:44 -0700 (PDT)
From: Paul Sztorc <truthcoin@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <7db9795a-53ff-4a1e-973e-d6be029d9022n@googlegroups.com>
In-Reply-To: <n4MR-H83t3x3B5yI8tjdTXR21smp_Ur7fRpqk_4EOc_im_zu0-9GlqxC1wl-gEzS__TdJNrf6XsV4XXOzxWn4kpdUocR3Xp8d6Uwo1m4ILw=@protonmail.com>
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <n4MR-H83t3x3B5yI8tjdTXR21smp_Ur7fRpqk_4EOc_im_zu0-9GlqxC1wl-gEzS__TdJNrf6XsV4XXOzxWn4kpdUocR3Xp8d6Uwo1m4ILw=@protonmail.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_257704_1331639532.1749520964843"
X-Original-Sender: Truthcoin@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_257704_1331639532.1749520964843
Content-Type: multipart/alternative; 
	boundary="----=_Part_257705_1953748239.1749520964843"

------=_Part_257705_1953748239.1749520964843
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

 >  the urgency with a six months deadline is nothing short of reckless.=20

But why would 6 months be considered "urgent"?

I think the tiniest amount of clarity would help. I propose a new table=20
(like the covenants support table), where we each self-sort ourselves into=
=20
whichever category describes us BEST:

1) Those who believe ...that each soft fork should take 5+ years (like=20
CTV). ...that we can only activate one soft fork at a time. ...that we must=
=20
debate and "agree" upon which one, to activate. ...that soft forks are a=20
dramatic event, different from other pull requests. ...that we need=20
"consensus" among humans to activate a soft fork. [Etc, etc]
2) Those who would prefer Bitcoin development to revert, more back toward=
=20
the way things were, pre-SegWit drama. In other words: we can activate=20
multiple soft forks at once ; soft forks do not require "agreement" among=
=20
humans -- they just need to meet the same quality threshold as other=20
pull-requests ; we should merge any pull-request, if it is a good idea=20
(regardless of if it is a soft fork or not -- the soft fork part, only=20
affects when it is safe for users to rely on the feature). The [OP NOP / OP=
=20
Success]-style forks, are inherently very safe, ignore-able, and=20
reversible. In theory, we could activate 15 of these in the next release,=
=20
and then later change our mind, and "deactivate" any (or all) of these (by=
=20
banning that opcode from ever being spent to/from again). In that=20
hypothetical scenario (very different from ours today), we would=20
preemptively explain (to users), that all "new opcodes" (less than a year=
=20
old), are "experimental", and may be "deactivated" at any time -- each user=
=20
could decide for themselves if they want to take this risk (during the=20
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=20
they should stand behind that point of view.

People seem to want it both ways -- on one hand, reluctant to stick their=
=20
neck out for any particular soft fork; but, on the other hand, too ashamed=
=20
to admit that they are quietly handcuffing the Bitcoin project to the "5+=
=20
years per softfork", bike-shedding timeline.

Cheers,
Paul

P.S. I have never used google groups before so I hope this email goes out=
=20
correctly.=20

On Monday, June 9, 2025 at 5:17:54=E2=80=AFPM UTC-4 Antoine Poinsot wrote:

> James, cosigners,
>
> I am sympathetic to the idea of a CTV+CSFS soft fork, mainly for its=20
> flagship use case: LN-Symmetry.
>
> However i think it is premature to call for a "final review and=20
> activation" of these opcodes when
> there is still:
> - disagreement between Bitcoin protocol developers/researchers that it is=
=20
> the way to go for enabling
> more expressive scripting capabilities in Bitcoin[^0];
> - disagreement between Bitcoin developers on how the functionality of at=
=20
> least one of the proposed
> opcodes should be achieved[^1];
> - no review after three months, from any of the champions or signers of=
=20
> 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=20
> demonstrated. As a point of
> comparison Greg Sanders provided motivation for `ANYPREVOUT`, a soft fork=
=20
> that no one even called
> to be "finally reviewed and activated", by publishing a detailed proof of=
=20
> concept of LN-Symmetry
> (with full specification as a BOLT draft + an implementation in one of th=
e=20
> major Lightning clients).
>
> A comprehensive exploration gives confidence a use case is actually=20
> realistic in practice. Of course
> it's not necessary to go to such lengths just to demonstrate it to be=20
> *possible*, but it is
> reasonable to expect a champion to have something to show if they are=20
> calling for changing Bitcoin.
> Fortunately i hear some have taken upon themselves to further explore=20
> LN-Symmetry and multiparty
> channels using CTV+CSFS, which could provide tangible motivation for the=
=20
> soft fork. Let's see what
> they come up with.
>
> Finally, it seems the post contains a built-in assumption that Bitcoin=20
> Core contributors are
> detached from the research in more expressive scripting capabilities. It=
=20
> is incorrect. A number of
> individuals have been involved both with Bitcoin Core development and=20
> Bitcoin protocol research,
> with substantial contributions in both areas.
>
> Therefore it seems the stalling state of the CTV+CSFS proposal is not due=
=20
> to apathy as this open
> letter would lead to believe, but controversy on the content of the=20
> proposal among Bitcoin protocol
> developers as well as a lack of involvement from the part of champions in=
=20
> reaching consensus.
>
> In these conditions calling for an impending change to Bitcoin's consensu=
s=20
> 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=
=20
> scripting capabilities in
> Bitcoin. The path forward is by building consensus on the basis of strong=
=20
> technical arguments, and
> the politics of pushing for the premature activation of a consensus chang=
e=20
> are working against it.
>
> Best,
> Antoine Poinsot
>
>
> [^0]:=20
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-s=
tep-towards-covenants/1509/14
> https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4...@mattcorallo.com=20
> <https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4-ac51-b881d8df9f01@ma=
ttcorallo.com>
> [^1]:=20
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-s=
tep-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=
>=20
> wrote:
>
> > Good morning,
> >=20
> > A letter has been published advocating for the final review and
> > activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK
> > (BIP-348).
> >=20
> > The full text of the letter can be found at https://ctv-csfs.com. It is
> > reproduced below.
> >=20
> > ---
> >=20
> > To the technical bitcoin community,
> >=20
> > 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.
> >=20
> > 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 bot=
h
> > safe and widely demanded.
> >=20
> > 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.
> >=20
> > CSFS is a primitive opcode that has been deployed to Blockstream=E2=80=
=99s
> > Elements for at least 8 years. It represents no significant
> > computational burden over bitcoin=E2=80=99s 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.
> >=20
> > 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 fo=
r
> > rigorous final review and activation planning.
> >=20
> > This request isn't meant to suggest that these contributors dictate the
> > consensus process, but rather it is an acknowledgement that before thes=
e
> > opcodes can be activated, they must be implemented in the most widely
> > used bitcoin client.
> >=20
> > As application and protocol developers, we are convinced of the
> > significant benefits that these changes would bring to end users of
> > bitcoin =E2=80=93 even if only considering their use for layer 1 securi=
ty and
> > layer 2 scaling solutions. We are optimistic that given the limited siz=
e
> > 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.
> >=20
> > Signed,
> >=20
> > 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=E2=80=99Beirne (@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)
> >=20
> >=20
> > --
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51be=
eb765163n%40googlegroups.com
> .
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
7db9795a-53ff-4a1e-973e-d6be029d9022n%40googlegroups.com.

------=_Part_257705_1953748239.1749520964843
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


&gt;=C2=A0 the urgency with a six months deadline is nothing short of reckl=
ess.

<br /><br />But why would 6 months be considered "urgent"?<br /><br />I thi=
nk the tiniest amount of clarity would help. I propose a new table (like th=
e covenants support table), where we each self-sort ourselves into whicheve=
r category describes us BEST:<br /><br />1)
 Those who believe ...that each soft fork should take 5+ years (like=20
CTV). ...that we can only activate one soft fork at a time. ...that we=20
must debate and "agree" upon which one, to activate. ...that soft forks=20
are a dramatic event, different from other pull requests. ...that we=20
need "consensus" among humans to activate a soft fork. [Etc, etc]<br /> 2)
 Those who would prefer Bitcoin development to revert, more back toward=20
the way things were, pre-SegWit drama. In other words: we can activate=20
multiple soft forks at once ; soft forks do not require "agreement"=20
among humans -- they just need to meet the same quality threshold as=20
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,=20
only affects when it is safe for users to rely on the feature). The [OP=20
NOP / OP Success]-style forks, are inherently very safe, ignore-able,=20
and reversible. In theory, we could activate 15 of these in the next=20
release, and then later change our mind, and "deactivate" any (or all)=20
of these (by banning that opcode from ever being spent to/from again).=20
In that hypothetical scenario (very different from ours today), we would
 preemptively explain (to users), that all "new opcodes" (less than a=20
year old), are "experimental", and may be "deactivated" at any time --=20
each user could decide for themselves if they want to take this risk=20
(during the first 12 months).<div>3) Those unwilling to clarify their opini=
on.<br /><br />If people think "2 soft forks per 10 years" is the right way=
 to go, then they should stand behind that point of view.<br /><br />People
 seem to want it both ways -- on one hand, reluctant to stick=20
their neck out for any particular soft fork; but, on the other hand, too=20
ashamed to admit that they are quietly handcuffing the Bitcoin project to t=
he=20
"5+ years per softfork", bike-shedding timeline.<br /><br />Cheers,<br />Pa=
ul</div><br />P.S. I have never used google groups before so I hope this em=
ail goes out correctly.

<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_att=
r">On Monday, June 9, 2025 at 5:17:54=E2=80=AFPM UTC-4 Antoine Poinsot wrot=
e:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex=
; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">James, cos=
igners,
<br>
<br>I am sympathetic to the idea of a CTV+CSFS soft fork, mainly for its fl=
agship use case: LN-Symmetry.
<br>
<br>However i think it is premature to call for a &quot;final review and ac=
tivation&quot; of these opcodes when
<br>there is still:
<br>- disagreement between Bitcoin protocol developers/researchers that it =
is the way to go for enabling
<br>  more expressive scripting capabilities in Bitcoin[^0];
<br>- disagreement between Bitcoin developers on how the functionality of a=
t least one of the proposed
<br>  opcodes should be achieved[^1];
<br>- no review after three months, from any of the champions or signers of=
 this letter, on the PR for
<br>  integrating one of the two proposed opcodes to the test network[^2].
<br>
<br>The flagship use case of the proposal has also not been properly demons=
trated. As a point of
<br>comparison Greg Sanders provided motivation for `ANYPREVOUT`, a soft fo=
rk that no one even called
<br>to be &quot;finally reviewed and activated&quot;, by publishing a detai=
led proof of concept of LN-Symmetry
<br>(with full specification as a BOLT draft + an implementation in one of =
the major Lightning clients).
<br>
<br>A comprehensive exploration gives confidence a use case is actually rea=
listic in practice. Of course
<br>it&#39;s not necessary to go to such lengths just to demonstrate it to =
be *possible*, but it is
<br>reasonable to expect a champion to have something to show if they are c=
alling for changing Bitcoin.
<br>Fortunately i hear some have taken upon themselves to further explore L=
N-Symmetry and multiparty
<br>channels using CTV+CSFS, which could provide tangible motivation for th=
e soft fork. Let&#39;s see what
<br>they come up with.
<br>
<br>Finally, it seems the post contains a built-in assumption that Bitcoin =
Core contributors are
<br>detached from the research in more expressive scripting capabilities. I=
t is incorrect. A number of
<br>individuals have been involved both with Bitcoin Core development and B=
itcoin protocol research,
<br>with substantial contributions in both areas.
<br>
<br>Therefore it seems the stalling state of the CTV+CSFS proposal is not d=
ue to apathy as this open
<br>letter would lead to believe, but controversy on the content of the pro=
posal among Bitcoin protocol
<br>developers as well as a lack of involvement from the part of champions =
in reaching consensus.
<br>
<br>In these conditions calling for an impending change to Bitcoin&#39;s co=
nsensus rules seems unadvisable,
<br>and the urgency with a six months deadline is nothing short of reckless=
.
<br>
<br>I remain confident we can make progress toward enabling more expressive=
 scripting capabilities in
<br>Bitcoin. The path forward is by building consensus on the basis of stro=
ng technical arguments, and
<br>the politics of pushing for the premature activation of a consensus cha=
nge are working against it.
<br>
<br>Best,
<br>Antoine Poinsot
<br>
<br>
<br>[^0]: <a href=3D"https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-con=
sensus-on-a-first-step-towards-covenants/1509/14" target=3D"_blank" rel=3D"=
nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-=
step-towards-covenants/1509/14&amp;source=3Dgmail&amp;ust=3D174960581318500=
0&amp;usg=3DAOvVaw2hMB5SO4xxu4A_HAOzXMxs">https://delvingbitcoin.org/t/ctv-=
csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/14</a>
<br>      <a href=3D"https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4-ac=
51-b881d8df9f01@mattcorallo.com" target=3D"_blank" rel=3D"nofollow" data-sa=
feredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gnusha.=
org/pi/bitcoindev/6f78b702-4bd0-4aa4-ac51-b881d8df9f01@mattcorallo.com&amp;=
source=3Dgmail&amp;ust=3D1749605813185000&amp;usg=3DAOvVaw0Wnay8X18Yyh-lzId=
mt7Nl">https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4...@mattcorallo.c=
om</a>
<br>[^1]: <a href=3D"https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-con=
sensus-on-a-first-step-towards-covenants/1509/58" target=3D"_blank" rel=3D"=
nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-=
step-towards-covenants/1509/58&amp;source=3Dgmail&amp;ust=3D174960581318500=
0&amp;usg=3DAOvVaw0fdMxKtEHmCMgkJHE-aca4">https://delvingbitcoin.org/t/ctv-=
csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/58</a>
<br>[^2]: <a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/72=
" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.go=
ogle.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin-inquisition/bitcoin=
/pull/72&amp;source=3Dgmail&amp;ust=3D1749605813185000&amp;usg=3DAOvVaw3AR7=
4osriCcnZA0BLFQaZT">https://github.com/bitcoin-inquisition/bitcoin/pull/72<=
/a>
<br>[^3]: <a href=3D"https://delvingbitcoin.org/t/ln-symmetry-project-recap=
/359" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://ww=
w.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.org/t/ln-symmetry-p=
roject-recap/359&amp;source=3Dgmail&amp;ust=3D1749605813185000&amp;usg=3DAO=
vVaw2E_hkjxckb20aP_1dZ4S_o">https://delvingbitcoin.org/t/ln-symmetry-projec=
t-recap/359</a>
<br>
<br>
<br>On Monday, June 9th, 2025 at 7:54 AM, James O&#39;Beirne &lt;<a href da=
ta-email-masked rel=3D"nofollow">james....@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Good morning,
<br>&gt;=20
<br>&gt; A letter has been published advocating for the final review and
<br>&gt; activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROM=
STACK
<br>&gt; (BIP-348).
<br>&gt;=20
<br>&gt; The full text of the letter can be found at <a href=3D"https://ctv=
-csfs.com" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Den&amp;q=3Dhttps://ctv-csfs.com&amp;source=3Dgma=
il&amp;ust=3D1749605813185000&amp;usg=3DAOvVaw0JPfbgaslm_KZvarOwji4K">https=
://ctv-csfs.com</a>. It is
<br>&gt; reproduced below.
<br>&gt;=20
<br>&gt; ---
<br>&gt;=20
<br>&gt; To the technical bitcoin community,
<br>&gt;=20
<br>&gt; We believe that the best next step for bitcoin would be to activat=
e
<br>&gt; OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK (CS=
FS,
<br>&gt; BIP-348). These opcodes enable functionality for a broad set of us=
es
<br>&gt; that will allow bitcoin to preserve and expand its role as a scarc=
e,
<br>&gt; censorship-resistant store of value.
<br>&gt;=20
<br>&gt; While there are a few promising proposals to improve bitcoin at th=
e
<br>&gt; consensus layer which may someday be deployed, we believe that CTV=
 and
<br>&gt; CSFS are uniquely well reviewed, simple, and have been proven to b=
e both
<br>&gt; safe and widely demanded.
<br>&gt;=20
<br>&gt; CTV was first formalized in BIP-119 over 5 years ago. Despite many
<br>&gt; attempts at refinement or replacement, it has remained the most wi=
dely
<br>&gt; preferred method for enforcing pregenerated transaction sequences =
using
<br>&gt; consensus. It unlocks valuable functionality for scaling solutions=
,
<br>&gt; vaults, congestion control, non-custodial mining, discreet log
<br>&gt; contracts, and more.
<br>&gt;=20
<br>&gt; CSFS is a primitive opcode that has been deployed to Blockstream=
=E2=80=99s
<br>&gt; Elements for at least 8 years. It represents no significant
<br>&gt; computational burden over bitcoin=E2=80=99s most often used opcode=
, OP_CHECKSIG.
<br>&gt; It can be combined with CTV to implement ln-symmetry, a longstandi=
ng
<br>&gt; improvement to Lightning. It also unlocks a variety of other use c=
ases.
<br>&gt;=20
<br>&gt; We respectfully ask Bitcoin Core contributors to prioritize the re=
view
<br>&gt; and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 =
or
<br>&gt; similar) within the next six months. We believe this timeline allo=
ws for
<br>&gt; rigorous final review and activation planning.
<br>&gt;=20
<br>&gt; This request isn&#39;t meant to suggest that these contributors di=
ctate the
<br>&gt; consensus process, but rather it is an acknowledgement that before=
 these
<br>&gt; opcodes can be activated, they must be implemented in the most wid=
ely
<br>&gt; used bitcoin client.
<br>&gt;=20
<br>&gt; As application and protocol developers, we are convinced of the
<br>&gt; significant benefits that these changes would bring to end users o=
f
<br>&gt; bitcoin =E2=80=93 even if only considering their use for layer 1 s=
ecurity and
<br>&gt; layer 2 scaling solutions. We are optimistic that given the limite=
d size
<br>&gt; and scope of these changes in both concept and implementation, the=
y
<br>&gt; represent a realistic next step in the continuing and important wo=
rk of
<br>&gt; preserving bitcoin&#39;s unique promise.
<br>&gt;=20
<br>&gt; Signed,
<br>&gt;=20
<br>&gt; Abdel (Starkware)
<br>&gt; Andrew Poelstra (@apoelstra)
<br>&gt; Ben Carman (@benthecarman)
<br>&gt; Ben Kaufman (@ben-kaufman)
<br>&gt; Brandon Black (@reardencode)
<br>&gt; Brian Langel (for Five Bells)
<br>&gt; Buck Perley (@puckberley)
<br>&gt; Calle (Cashu)
<br>&gt; Calvin Kim (@kcalvinalvin)
<br>&gt; Chun Wang (f2pool)
<br>&gt; Christian Decker (@cdecker)
<br>&gt; Coinjoined Chris (Bitsurance.eu)
<br>&gt; Evan Kaloudis (for Zeus)
<br>&gt; fiatjaf (@fiatjaf)
<br>&gt; Floppy (@1440000bytes)
<br>&gt; Gary Krause (@average-gary)
<br>&gt; Harsha Goli (@arshbot)
<br>&gt; Hunter Beast (@cryptoquick)
<br>&gt; Jad Mubaslat (@champbronc2)
<br>&gt; James O=E2=80=99Beirne (@jamesob)
<br>&gt; Jameson Lopp (@jlopp)
<br>&gt; Johan Halseth (@halseth)
<br>&gt; Luke Childs (@lukechilds)
<br>&gt; Matt Black (for Atomic Finance)
<br>&gt; Michael Tidwell (@miketwenty1)
<br>&gt; Nick Hansen (for Luxor Mining)
<br>&gt; Nitesh (@nitesh_btc)
<br>&gt; nvk (@nvk)
<br>&gt; Owen Kemeys (for Foundation)
<br>&gt; Paul Sztorc (@psztorc)
<br>&gt; Portland.HODL (for MARA Pool)
<br>&gt; Rijndael (@rot13maxi)
<br>&gt; Rob Hamilton (@rob1ham)
<br>&gt; Robin Linus (@RobinLinus)
<br>&gt; Sanket Kanjalkar (@sanket1729)
<br>&gt; Sean Ryan (Anchorage)
<br>&gt; Seth for Privacy (for Cake Wallet)
<br>&gt; Simanta Gautam (Alpen Labs)
<br>&gt; Steven Roose (@stevenroose)
<br>&gt; stutxo (@stutxo)
<br>&gt; Talip (@otaliptus)
<br>&gt; mononaut (@mononautical)
<br>&gt; vnprc (@vnprc)
<br>&gt;=20
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.co=
m" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/=
a86c2737-db79-4f54-9c1d-51beeb765163n%2540googlegroups.com&amp;source=3Dgma=
il&amp;ust=3D1749605813185000&amp;usg=3DAOvVaw3ltY90fcFT_a41ZZ3FVyqw">https=
://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb76516=
3n%40googlegroups.com</a>.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/7db9795a-53ff-4a1e-973e-d6be029d9022n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/7db9795a-53ff-4a1e-973e-d6be029d9022n%40googlegroups.com</a>.<br />

------=_Part_257705_1953748239.1749520964843--

------=_Part_257704_1331639532.1749520964843--