[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 --]