From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <7db9795a-53ff-4a1e-973e-d6be029d9022n@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 > > [^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 =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 >=C2=A0 the urgency with a six months deadline is nothing short of reckl= ess.

But why would 6 months be considered "urgent"?

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:

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]
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).
3) Those unwilling to clarify their opini= on.

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=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.

Cheers,
Pa= ul

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

On Monday, June 9, 2025 at 5:17:54=E2=80=AFPM UTC-4 Antoine Poinsot wrot= e:
James, cos= igners,

I am sympathetic to the idea of a CTV+CSFS soft fork, mainly for its fl= agship use case: LN-Symmetry.

However i think it is premature to call for a "final review and ac= tivation" 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 a= t 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 demons= trated. As a point of
comparison Greg Sanders provided motivation for `ANYPREVOUT`, a soft fo= rk that no one even called
to be "finally reviewed and activated", by publishing a detai= led 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 rea= listic 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 c= alling for changing Bitcoin.
Fortunately i hear some have taken upon themselves to further explore L= N-Symmetry and multiparty
channels using CTV+CSFS, which could provide tangible motivation for th= e 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. I= t is incorrect. A number of
individuals have been involved both with Bitcoin Core development and B= itcoin protocol research,
with substantial contributions in both areas.

Therefore it seems the stalling state of the CTV+CSFS proposal is not d= ue to apathy as this open
letter would lead to believe, but controversy on the content of the pro= posal 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 co= nsensus 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 stro= ng technical arguments, and
the politics of pushing for the premature activation of a consensus cha= nge 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.c= om
[^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<= /a>
[^3]: https://delvingbitcoin.org/t/ln-symmetry-projec= t-recap/359


On Monday, June 9th, 2025 at 7:54 AM, James O'Beirne <james....@gmail.com> wrote:

> Good morning,
>=20
> A letter has been published advocating for the final review and
> activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROM= STACK
> (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 activat= e
> OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK (CS= FS,
> BIP-348). These opcodes enable functionality for a broad set of us= es
> that will allow bitcoin to preserve and expand its role as a scarc= e,
> censorship-resistant store of value.
>=20
> While there are a few promising proposals to improve bitcoin at th= e
> consensus layer which may someday be deployed, we believe that CTV= and
> CSFS are uniquely well reviewed, simple, and have been proven to b= e both
> 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 wi= dely
> 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 longstandi= ng
> improvement to Lightning. It also unlocks a variety of other use c= ases.
>=20
> We respectfully ask Bitcoin Core contributors to prioritize the re= view
> and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 = or
> similar) within the next six months. We believe this timeline allo= ws for
> rigorous final review and activation planning.
>=20
> This request isn't meant to suggest that these contributors di= ctate the
> consensus process, but rather it is an acknowledgement that before= these
> opcodes can be activated, they must be implemented in the most wid= ely
> used bitcoin client.
>=20
> As application and protocol developers, we are convinced of the
> significant benefits that these changes would bring to end users o= f
> bitcoin =E2=80=93 even if only considering their use for layer 1 s= ecurity and
> layer 2 scaling solutions. We are optimistic that given the limite= d size
> and scope of these changes in both concept and implementation, the= y
> represent a realistic next step in the continuing and important wo= rk 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= 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-51beeb76516= 3n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/7db9795a-53ff-4a1e-973e-d6be029d9022n%40googlegroups.com.
------=_Part_257705_1953748239.1749520964843-- ------=_Part_257704_1331639532.1749520964843--