[bitcoindev] CTV + CSFS: a letter

[bitcoindev] CTV + CSFS: a letter

[James O'Beirne]

[-- Attachment #1.1: Type: text/plain, Size: 4087 bytes --]

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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4752 bytes --]

Re: [bitcoindev] CTV + CSFS: a letter

[Michael Folkson]

Hi James

I'm losing track of where I haven't been blocked and am free to ask
questions. You've personally blocked me on X so I can't ask there and
I'm not sure what my current status is on the Core GitHub repo,
Delving Bitcoin, this mailing list. Perhaps if you're going to be
leading this attempt to move towards an activation attempt of a
consensus rule change there can be a forum set up where those who
would like to ask questions and/or have some default skepticism aren't
heavily censored or blocked. Or perhaps this is such a forum, I don't
know.

I've tried to follow your personal journey (despite you making it hard
by blocking me) on this let alone the entire community's journey on
this.

It seems like until recently (May 2025) you were a proponent of BIP
345 (OP_VAULT) and have argued that that should be activated in the
past. On Delving [0] in May 2025 you stated:

"OP_VAULT (BIP-345) has been essentially replaced by @salvatoshi’s
OP_CHECKCONTRACTVERIFY (CCV)"

Having read that I assumed you would be working on CCV so I'm quite
surprised that a month later you're now proposing that CTV and CSFS be
prepared for activation.

What is the current status of CCV? Why aren't you working towards CCV
being activated and why should CTV and CSFS be activated prior to CCV?

I'm finding it a little bewildering just trying to follow your
personal views on this and I suspect those who you are asking to
prioritize the review of CTV and CSFS in the Core repo in the next 6
months might be in a similar boat. If your view is changing month to
month have you finally settled on CTV and CSFS should definitely be
activated or might your view change again in the near future (e.g. the
addition of CCV or some other variation)? In my opinion to convince
the broader community these should be activated imminently probably
requires James to be consistently convinced from month to month.

Thanks
Michael

[0]: https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670

On Mon, Jun 9, 2025 at 2:54 PM James O'Beirne <james.obeirne@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+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com.



-- 
Michael Folkson
Personal email: michaelfolkson@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/CAFvNmHRvjbo0OCFa3edCERXRFsz6yiAAPgzWrX5YxdtR9a4GiA%40mail.gmail.com.

Re: [bitcoindev] CTV + CSFS: a letter

[Matt Corallo]

First of all, lol, we're really doing sign-on letters again? Great way to discourage people from 
doing things.

That said, I have yet to see a reasoned explanation of why we should prefer CTV over TXHASH. Any 
time I bring it up I get a few handwave arguments about "that would require bikeshedding", but I 
don't see why that is an argument. Preferring to do something worse because something better would 
require someone reasonable pick some reasonable encoding is not a good way to do engineering.

Maybe one of the letter-signers wants to provide an explanation for their view?

Matt

On 6/9/25 7:40 AM, James O'Beirne 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+unsubscribe@googlegroups.com <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a86c2737- 
> db79-4f54-9c1d-51beeb765163n%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/ 
> a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.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/6f78b702-4bd0-4aa4-ac51-b881d8df9f01%40mattcorallo.com.

Re: [bitcoindev] CTV + CSFS: a letter

[James O'Beirne]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Mon, Jun 9, 2025 at 8:51 AM Michael Folkson <michaelfolkson@gmail.com>
wrote:
> Having read that I assumed you would be working on CCV so I'm quite
> surprised that a month later you're now proposing that CTV and CSFS be
> prepared for activation.

I have consistently supported CTV for upwards of 3 years now. This should
be pretty clear based on a cursory read of my VAULT BIP's introduction:
https://github.com/bitcoin/bips/blob/master/bip-0345.mediawiki#introduction

In fact, I was at one point listed as a co-author because I was championing
it: https://github.com/bitcoin/bips/pull/1482

I like CCV, but in my opinion it needs more time to be scrutinized by the
community.

Best,
James

-- 
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/CAPfvXfKfAgVrFht8AUBOoyn28xwzHNr5BMg__OtRZfyBi1C1yw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 1888 bytes --]

Re: [bitcoindev] CTV + CSFS: a letter

[James O'Beirne]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

On Mon, Jun 9, 2025 at 9:51 AM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
> That said, I have yet to see a reasoned explanation of why we should
prefer CTV over TXHASH.

From the author of TXHASH himself on Delving Bitcoin
(
https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/15
):

> Having implemented TXHASH, I would definitely not say that
> it “simplifies the change”. The difference in both technical debt and
> potential for bugs is an order of magnitude bigger for TXHASH than for
> CTV. (Not to say that I don’t think TXHASH would be worthwhile, but I
> will definitely say that it has not received the attention I had
expected,
> so I would definitely not want to put it on the table anytime soon.)

The use-cases that might merit such a jump up in complexity over CTV
have not been enumerated to my knowledge. CTV also includes
upgrade hooks to incorporate modifications should these additional
uses be more fully understood.

Best,
James

-- 
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/CAPfvXf%2Bt33u1ghz39cqYn4k5ErmxTkUv0njF9Zwbz_2UkdTjAg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 2571 bytes --]

Re: [bitcoindev] CTV + CSFS: a letter

[Michael Folkson]

> I have consistently supported CTV for upwards of 3 years now. This should
be pretty clear based on a cursory read of my VAULT BIP's introduction:
https://github.com/bitcoin/bips/blob/master/bip-0345.mediawiki#introduction

Sure but CTV has never been enough for what you personally want to do
(your flavor of vaults). You need OP_VAULT, OP_CCV or OP_CSFS right?

I don't mean to be a smart ass, I know how fiendishly difficult and
frustrating this covenants maze is with so many subtly different
views. But I think it is a fair challenge to try to understand exactly
what you want/need and whether you're going to want CCV etc in
addition at a later date or not.

Thanks
Michael

On Mon, Jun 9, 2025 at 5:41 PM James O'Beirne <james.obeirne@gmail.com> wrote:
>
> On Mon, Jun 9, 2025 at 8:51 AM Michael Folkson <michaelfolkson@gmail.com> wrote:
> > Having read that I assumed you would be working on CCV so I'm quite
> > surprised that a month later you're now proposing that CTV and CSFS be
> > prepared for activation.
>
> I have consistently supported CTV for upwards of 3 years now. This should
> be pretty clear based on a cursory read of my VAULT BIP's introduction:
> https://github.com/bitcoin/bips/blob/master/bip-0345.mediawiki#introduction
>
> In fact, I was at one point listed as a co-author because I was championing
> it: https://github.com/bitcoin/bips/pull/1482
>
> I like CCV, but in my opinion it needs more time to be scrutinized by the
> community.
>
> Best,
> James



-- 
Michael Folkson
Personal email: michaelfolkson@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/CAFvNmHSQDkR9L7SAu95FmfASdrdjFPUmohEncjNcPHx2q4_9Fw%40mail.gmail.com.

Re: [bitcoindev] CTV + CSFS: a letter

[Matt Corallo]

On 6/9/25 10:43 AM, James O'Beirne wrote:
> On Mon, Jun 9, 2025 at 9:51 AM Matt Corallo <lf-lists@mattcorallo.com <mailto:lf- 
> lists@mattcorallo.com>> wrote:
>  > That said, I have yet to see a reasoned explanation of why we should prefer CTV over TXHASH.
> 
>  From the author of TXHASH himself on Delving Bitcoin
> (https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards- 
> covenants/1509/15 <https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step- 
> towards-covenants/1509/15>):
> 
>  > Having implemented TXHASH, I would definitely not say that
>  > it “simplifies the change”.

Who claimed TXHASH is simpler than CTV?

>  > The difference in both technical debt and
>  > potential for bugs is an order of magnitude bigger for TXHASH than for
>  > CTV.

I mean, sure, compared to something trivial doing something marginally-trivial has a lot bigger 
surface area. But that isn't really an argument unless we're talking about something truly 
complicated, and TXHASH absolutely is not.

>  > (Not to say that I don’t think TXHASH would be worthwhile, but I
>  > will definitely say that it has not received the attention I had expected,
>  > so I would definitely not want to put it on the table anytime soon.)

I mean there's still debate around the exact format of CTV commitments (eg whether it commits to 
scriptSigs, if it works outside of segwit, etc), saying that there's debate over the format of 
TXHASH isn't exactly a compelling argument either? Yes, it needs some work, but the time we'll 
invest in CTV isn't all that different from the time we'll invest in TXHASH, once we pick a direction.

> The use-cases that might merit such a jump up in complexity over CTV
> have not been enumerated to my knowledge.

This is a much better argument :). I'm a bit skeptical, though, that its quite this cut-and-dry. For 
example, the utter hack of the BitVM-with-CTV variant pretty clearly points to us needing a more 
fully featured commitment gadget to enable these things without the nonsense they had to resort to.

Further, we should think at least somewhat about what we think a reasonable end state is. As far as 
I understand, most proponents of CTV+CSFS do not think that CTV+CSFS is *all* we want, but rather a 
first step towards some goal. If that goal includes more flexible tx field commitments (I imagine it 
certainly does!) then we should do that, rather than taking a detour we should make progress towards 
the eventual goal!

> CTV also includes
> upgrade hooks to incorporate modifications should these additional
> uses be more fully understood.

I do not understand why people make this argument. Yes, the encoding of the opcode allows you to 
turn it into an OP_NOP (or SUCCESS or whatever), that doesn't make it "upgrade hook"-friendly. If we 
think that we just want to do CTV but we want CTV to be upgradable later to be TXHASH, then we first 
need to define the TXHASH hash and bitfield format, so that we can take the subset of it that 
captures CTV and hard-code that. But, of course, if we do that work we should clearly do TXHASH :).

These really feel like the same arguments again and again. I just don't find them even remotely 
compelling. "Oh, well, if we want to figure out TXHASH someone would have to define a bitfield 
format and that will take years" is just nonsense. Hell, its already done! Maybe we want to tweak 
it, but honestly bikeshedding over a specific bitfield format sounds like it'll take a hell of a lot 
less time than trying to make sure we work out all the cases for what someone might want to commit 
to that we want them to commit to but not more and fix a specific set of commitments!

Matt

-- 
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/01f49d64-838e-4311-bf79-8c4130b40c8e%40mattcorallo.com.

Re: [bitcoindev] CTV + CSFS: a letter

['Antoine Poinsot' via Bitcoin Development Mailing List]

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-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.obeirne@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+unsubscribe@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/n4MR-H83t3x3B5yI8tjdTXR21smp_Ur7fRpqk_4EOc_im_zu0-9GlqxC1wl-gEzS__TdJNrf6XsV4XXOzxWn4kpdUocR3Xp8d6Uwo1m4ILw%3D%40protonmail.com.

Re: [bitcoindev] CTV + CSFS: a letter

[/dev /fd0]

[-- Attachment #1: Type: text/plain, Size: 6315 bytes --]

Hi Matt,

> I mean, sure, compared to something trivial doing something
marginally-trivial has a lot bigger
> surface area. But that isn't really an argument unless we're talking
about something truly
> complicated, and TXHASH absolutely is not.

If you are referring to [BIP 346][0], it is not *marginally* trivial
compared to BIP 119. TxFieldSelector makes it super complex. That's without
even considering the possibilities when combined with CSFS.

> If that goal includes more flexible tx field commitments (I imagine it
> certainly does!) then we should do that, rather than taking a detour we
should make progress towards
> the eventual goal!

Sometimes the goal is easier to achieve through multiple steps with BIP 119
being the first step in this case. There are several reasons to prefer BIP
119 over BIP 346, and I have listed some of them below, based on rationales
shared in the [covenants support wiki][1]:

1. All the possible configurations need to be tested.
2. State carrying UTXOs will bloat the UTXO set.
3. BIP 346 could be activated in 2030 or later, once we better understand
how people are actually using covenants. This approach would be based on
real-world usage rather than premature optimization without sufficient data.

[0]:
https://github.com/bitcoin/bips/blob/debd349e6181d949cbea0691fcc0d67b265b02a8/bip-0346.md
[1]: https://en.bitcoin.it/wiki/Covenants_support

/dev/fd0
floppy disk guy

On Mon, Jun 9, 2025 at 11:23 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

>
>
> On 6/9/25 10:43 AM, James O'Beirne wrote:
> > On Mon, Jun 9, 2025 at 9:51 AM Matt Corallo <lf-lists@mattcorallo.com
> <mailto:lf-
> > lists@mattcorallo.com>> wrote:
> >  > That said, I have yet to see a reasoned explanation of why we should
> prefer CTV over TXHASH.
> >
> >  From the author of TXHASH himself on Delving Bitcoin
> > (
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-
> > covenants/1509/15 <
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-
> > towards-covenants/1509/15>):
> >
> >  > Having implemented TXHASH, I would definitely not say that
> >  > it “simplifies the change”.
>
> Who claimed TXHASH is simpler than CTV?
>
> >  > The difference in both technical debt and
> >  > potential for bugs is an order of magnitude bigger for TXHASH than for
> >  > CTV.
>
> I mean, sure, compared to something trivial doing something
> marginally-trivial has a lot bigger
> surface area. But that isn't really an argument unless we're talking about
> something truly
> complicated, and TXHASH absolutely is not.
>
> >  > (Not to say that I don’t think TXHASH would be worthwhile, but I
> >  > will definitely say that it has not received the attention I had
> expected,
> >  > so I would definitely not want to put it on the table anytime soon.)
>
> I mean there's still debate around the exact format of CTV commitments (eg
> whether it commits to
> scriptSigs, if it works outside of segwit, etc), saying that there's
> debate over the format of
> TXHASH isn't exactly a compelling argument either? Yes, it needs some
> work, but the time we'll
> invest in CTV isn't all that different from the time we'll invest in
> TXHASH, once we pick a direction.
>
> > The use-cases that might merit such a jump up in complexity over CTV
> > have not been enumerated to my knowledge.
>
> This is a much better argument :). I'm a bit skeptical, though, that its
> quite this cut-and-dry. For
> example, the utter hack of the BitVM-with-CTV variant pretty clearly
> points to us needing a more
> fully featured commitment gadget to enable these things without the
> nonsense they had to resort to.
>
> Further, we should think at least somewhat about what we think a
> reasonable end state is. As far as
> I understand, most proponents of CTV+CSFS do not think that CTV+CSFS is
> *all* we want, but rather a
> first step towards some goal. If that goal includes more flexible tx field
> commitments (I imagine it
> certainly does!) then we should do that, rather than taking a detour we
> should make progress towards
> the eventual goal!
>
> > CTV also includes
> > upgrade hooks to incorporate modifications should these additional
> > uses be more fully understood.
>
> I do not understand why people make this argument. Yes, the encoding of
> the opcode allows you to
> turn it into an OP_NOP (or SUCCESS or whatever), that doesn't make it
> "upgrade hook"-friendly. If we
> think that we just want to do CTV but we want CTV to be upgradable later
> to be TXHASH, then we first
> need to define the TXHASH hash and bitfield format, so that we can take
> the subset of it that
> captures CTV and hard-code that. But, of course, if we do that work we
> should clearly do TXHASH :).
>
> These really feel like the same arguments again and again. I just don't
> find them even remotely
> compelling. "Oh, well, if we want to figure out TXHASH someone would have
> to define a bitfield
> format and that will take years" is just nonsense. Hell, its already done!
> Maybe we want to tweak
> it, but honestly bikeshedding over a specific bitfield format sounds like
> it'll take a hell of a lot
> less time than trying to make sure we work out all the cases for what
> someone might want to commit
> to that we want them to commit to but not more and fix a specific set of
> commitments!
>
> Matt
>
> --
> 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/01f49d64-838e-4311-bf79-8c4130b40c8e%40mattcorallo.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/CALiT-ZqWjPM-dhAUfahG5AgNfQbLhn2Aa4%2BeLcrpugU4eZ4_vA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 8177 bytes --]

Re: [bitcoindev] CTV + CSFS: a letter

[Matt Corallo]

Note that you can always reply inline, you don't have to copy and paste quotes, your email client 
will do that for you :)

On 6/9/25 3:27 PM, /dev /fd0 wrote:
> Hi Matt,
> 
>  > I mean, sure, compared to something trivial doing something marginally-trivial has a lot bigger
>  > surface area. But that isn't really an argument unless we're talking about something truly
>  > complicated, and TXHASH absolutely is not.
> 
> If you are referring to [BIP 346][0], it is not /marginally/ trivial compared to BIP 119. 
> TxFieldSelector makes it super complex. That's without even considering the possibilities when 
> combined with CSFS.

The "marginally-trivial" comment was not in comparison to, rather in the general sense. taking 
hashes of various parts of the transaction based on a discriminator (with intermediate hashes and 
caching to avoid hashed-data blowups) is absolutely marginally-trivial in the context of recent soft 
fork complexity.

>  > If that goal includes more flexible tx field commitments (I imagine it
>  > certainly does!) then we should do that, rather than taking a detour we should make progress towards
>  > the eventual goal!
> 
> Sometimes the goal is easier to achieve through multiple steps with BIP 119 being the first step in 
> this case.

I believe you missed my comment addressing this specifically in the email you're replying to, let me 
paste it here:

 > I do not understand why people make this argument. Yes, the encoding of the opcode allows you to 
turn it into an OP_NOP (or SUCCESS or whatever), that doesn't make it "upgrade hook"-friendly. If we 
think that we just want to do CTV but we want CTV to be upgradable later to be TXHASH, then we first 
need to define the TXHASH hash and bitfield format, so that we can take the subset of it that 
captures CTV and hard-code that. But, of course, if we do that work we should clearly do TXHASH 🙂.

 > There are several reasons to prefer BIP 119 over BIP 346, and I have listed some of them
 > below, based on rationales shared in the [covenants support wiki][1]:
 >
> 1. All the possible configurations need to be tested.

I mean....okay? Yes? And? Come on, this isn't a lot of work.

> 2. State carrying UTXOs will bloat the UTXO set.

State carrying UTXOs will bloat the UTXO set worse if its done via BitVM/GC? Come on...

> 3. BIP 346 could be activated in 2030 or later, once we better understand how people are actually 
> using covenants. This approach would be based on real-world usage rather than premature optimization 
> without sufficient data.

This is similar to the argument I was replying to which you replied to here, and I think my original 
response still stands and wasn't responded to at all:

 > This is a much better argument 🙂. I'm a bit skeptical, though, that its quite this cut-and-dry. 
For example, the utter hack of the BitVM-with-CTV variant pretty clearly points to us needing a more 
fully featured commitment gadget to enable these things without the nonsense they had to resort to.

IOW, we have concrete use-cases already for TXHASH-over-CTV (at least in the sense that it would 
simplify things that are currently very hacky), and if it avoids a future soft fork by just enabling 
the full set of things today vs some narrow subset, I don't see why we shouldn't take on the extra 
month of work.

Matt

-- 
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/351b6327-08ab-4c2d-937c-521020978c82%40mattcorallo.com.