[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

[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

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

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: 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

[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

[/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.

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

[Paul Sztorc]

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

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

But why would 6 months be considered "urgent"?

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

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

If people think "2 soft forks per 10 years" is the right way to go, then 
they should stand behind that point of view.

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

Cheers,
Paul

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

On Monday, June 9, 2025 at 5:17:54 PM UTC-4 Antoine Poinsot wrote:

> James, cosigners,
>
> I am sympathetic to the idea of a CTV+CSFS soft fork, mainly for its 
> flagship use case: LN-Symmetry.
>
> However i think it is premature to call for a "final review and 
> activation" of these opcodes when
> there is still:
> - disagreement between Bitcoin protocol developers/researchers that it is 
> the way to go for enabling
> more expressive scripting capabilities in Bitcoin[^0];
> - disagreement between Bitcoin developers on how the functionality of at 
> least one of the proposed
> opcodes should be achieved[^1];
> - no review after three months, from any of the champions or signers of 
> this letter, on the PR for
> integrating one of the two proposed opcodes to the test network[^2].
>
> The flagship use case of the proposal has also not been properly 
> demonstrated. As a point of
> comparison Greg Sanders provided motivation for `ANYPREVOUT`, a soft fork 
> that no one even called
> to be "finally reviewed and activated", by publishing a detailed proof of 
> concept of LN-Symmetry
> (with full specification as a BOLT draft + an implementation in one of the 
> major Lightning clients).
>
> A comprehensive exploration gives confidence a use case is actually 
> realistic in practice. Of course
> it's not necessary to go to such lengths just to demonstrate it to be 
> *possible*, but it is
> reasonable to expect a champion to have something to show if they are 
> calling for changing Bitcoin.
> Fortunately i hear some have taken upon themselves to further explore 
> LN-Symmetry and multiparty
> channels using CTV+CSFS, which could provide tangible motivation for the 
> soft fork. Let's see what
> they come up with.
>
> Finally, it seems the post contains a built-in assumption that Bitcoin 
> Core contributors are
> detached from the research in more expressive scripting capabilities. It 
> is incorrect. A number of
> individuals have been involved both with Bitcoin Core development and 
> Bitcoin protocol research,
> with substantial contributions in both areas.
>
> Therefore it seems the stalling state of the CTV+CSFS proposal is not due 
> to apathy as this open
> letter would lead to believe, but controversy on the content of the 
> proposal among Bitcoin protocol
> developers as well as a lack of involvement from the part of champions in 
> reaching consensus.
>
> In these conditions calling for an impending change to Bitcoin's consensus 
> rules seems unadvisable,
> and the urgency with a six months deadline is nothing short of reckless.
>
> I remain confident we can make progress toward enabling more expressive 
> scripting capabilities in
> Bitcoin. The path forward is by building consensus on the basis of strong 
> technical arguments, and
> the politics of pushing for the premature activation of a consensus change 
> are working against it.
>
> Best,
> Antoine Poinsot
>
>
> [^0]: 
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/14
> https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4...@mattcorallo.com 
> <https://gnusha.org/pi/bitcoindev/6f78b702-4bd0-4aa4-ac51-b881d8df9f01@mattcorallo.com>
> [^1]: 
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/58
> [^2]: https://github.com/bitcoin-inquisition/bitcoin/pull/72
> [^3]: https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
>
>
> On Monday, June 9th, 2025 at 7:54 AM, James O'Beirne <james....@gmail.com> 
> wrote:
>
> > Good morning,
> > 
> > A letter has been published advocating for the final review and
> > activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK
> > (BIP-348).
> > 
> > The full text of the letter can be found at https://ctv-csfs.com. It is
> > reproduced below.
> > 
> > ---
> > 
> > To the technical bitcoin community,
> > 
> > We believe that the best next step for bitcoin would be to activate
> > OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK (CSFS,
> > BIP-348). These opcodes enable functionality for a broad set of uses
> > that will allow bitcoin to preserve and expand its role as a scarce,
> > censorship-resistant store of value.
> > 
> > While there are a few promising proposals to improve bitcoin at the
> > consensus layer which may someday be deployed, we believe that CTV and
> > CSFS are uniquely well reviewed, simple, and have been proven to be both
> > safe and widely demanded.
> > 
> > CTV was first formalized in BIP-119 over 5 years ago. Despite many
> > attempts at refinement or replacement, it has remained the most widely
> > preferred method for enforcing pregenerated transaction sequences using
> > consensus. It unlocks valuable functionality for scaling solutions,
> > vaults, congestion control, non-custodial mining, discreet log
> > contracts, and more.
> > 
> > CSFS is a primitive opcode that has been deployed to Blockstream’s
> > Elements for at least 8 years. It represents no significant
> > computational burden over bitcoin’s most often used opcode, OP_CHECKSIG.
> > It can be combined with CTV to implement ln-symmetry, a longstanding
> > improvement to Lightning. It also unlocks a variety of other use cases.
> > 
> > We respectfully ask Bitcoin Core contributors to prioritize the review
> > and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or
> > similar) within the next six months. We believe this timeline allows for
> > rigorous final review and activation planning.
> > 
> > This request isn't meant to suggest that these contributors dictate the
> > consensus process, but rather it is an acknowledgement that before these
> > opcodes can be activated, they must be implemented in the most widely
> > used bitcoin client.
> > 
> > As application and protocol developers, we are convinced of the
> > significant benefits that these changes would bring to end users of
> > bitcoin – even if only considering their use for layer 1 security and
> > layer 2 scaling solutions. We are optimistic that given the limited size
> > and scope of these changes in both concept and implementation, they
> > represent a realistic next step in the continuing and important work of
> > preserving bitcoin's unique promise.
> > 
> > Signed,
> > 
> > Abdel (Starkware)
> > Andrew Poelstra (@apoelstra)
> > Ben Carman (@benthecarman)
> > Ben Kaufman (@ben-kaufman)
> > Brandon Black (@reardencode)
> > Brian Langel (for Five Bells)
> > Buck Perley (@puckberley)
> > Calle (Cashu)
> > Calvin Kim (@kcalvinalvin)
> > Chun Wang (f2pool)
> > Christian Decker (@cdecker)
> > Coinjoined Chris (Bitsurance.eu)
> > Evan Kaloudis (for Zeus)
> > fiatjaf (@fiatjaf)
> > Floppy (@1440000bytes)
> > Gary Krause (@average-gary)
> > Harsha Goli (@arshbot)
> > Hunter Beast (@cryptoquick)
> > Jad Mubaslat (@champbronc2)
> > James O’Beirne (@jamesob)
> > Jameson Lopp (@jlopp)
> > Johan Halseth (@halseth)
> > Luke Childs (@lukechilds)
> > Matt Black (for Atomic Finance)
> > Michael Tidwell (@miketwenty1)
> > Nick Hansen (for Luxor Mining)
> > Nitesh (@nitesh_btc)
> > nvk (@nvk)
> > Owen Kemeys (for Foundation)
> > Paul Sztorc (@psztorc)
> > Portland.HODL (for MARA Pool)
> > Rijndael (@rot13maxi)
> > Rob Hamilton (@rob1ham)
> > Robin Linus (@RobinLinus)
> > Sanket Kanjalkar (@sanket1729)
> > Sean Ryan (Anchorage)
> > Seth for Privacy (for Cake Wallet)
> > Simanta Gautam (Alpen Labs)
> > Steven Roose (@stevenroose)
> > stutxo (@stutxo)
> > Talip (@otaliptus)
> > mononaut (@mononautical)
> > vnprc (@vnprc)
> > 
> > 
> > --
> > You received this message because you are subscribed to the Google 
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com
> .
>

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

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

Re: [bitcoindev] CTV + CSFS: a letter

[Andrew Poelstra]

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

Le Mon, Jun 09, 2025 at 04:40:52AM -0700, James O'Beirne a écrit :
> 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.
>

Hi all,


James, thanks for posting the letter. Matt, Antoine -- thanks for
replying quickly and respectfully even though you disagree with its
contents. Let me try to clarify my stance and why I signed onto the
letter.

First, the specific choice of CTV + CSFS would not be my first choice
on technical grounds. But what I'd like to see is something that is
technically "good enough" to enable vaults and some new script usecases,
while avoiding things that are politically toxic (which seems to be
pretty-much everything, but maybe right now does not include CTV+CSFS?).

So any arguments about CTV+CSFS on the technical merits I think are
great and within the purview of "review and integration" that the letter
talks about. (The word "final" I think is too strong and in retrospect
I think we should've dropped it. But it's super difficult when writing
these things to identify which specific points of language need to be
changed.)


Second, regarding the ultimatum language -- it was quite difficult to
strike a balance between "Core consists of volunteers working on their
on projects, with no obligation to anybody, and certainly no obligation
to drive forward consensus changes" and "this is a letter that says
nothing substantial at all".

The message that I want to communicate is: Bitcoin Core, like many
stakeholders, can veto any consensus changes because there will never be
a large enough contigent of the Bitcoin community confident to rush in
where angels dare to tread. But furthermore, if nobody in Core wants to
engage at all with consensus changes, then the result is effectively the
same as a veto.

Therefore, if we want to see an increase in script expressivity, somebody
on the Core team needs to help champion it. (There's no one in particular
I imagine this "somebody" to be, and I suppose you could accuse me of
hypocrisy since I'm not volunteering myself, even though I have the
social and technical knowledge to help. It could be, and probably would
have to be, somebody who isn't currently active on Core. But it needs to
be somebody willing and able to work within the Core review process, to
deal with ongoing rebases, etc.)


Third, I really really hope that this letter does not lead to further
brigading or twitter fights or whatever bleeding into the Github repo.
(This is the one point where I think that my fellow cosigners agree with
me fully.) But on the other hand, I don't think that I personally should
shy away from discussion to mitigate that risk; it needs to be mitigated
by more agressive moderation or by higher barriers to entry for people
posting on Core PRs.



Best
Andrew




-- 
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster

-- 
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/aEdoIvOgNNtT6L4s%40mail.wpsoftware.net.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoindev] CTV + CSFS: a letter

[David A. Harding]

On 2025-06-09 13:02, Andrew Poelstra wrote:
> if nobody in Core wants to
> engage at all with consensus changes, then the result is effectively 
> the
> same as a veto.

Hi Andrew and the other signatories,

Why do you think nobody in Core wants to engage at all with consensus 
changes (or, at least, specifically the proposals for CTV & CSFS)?

The usual purpose of an open letter is to generate public pressure 
against the target (otherwise, if you didn't want to generate public 
pressure, you would send a private letter).  Does that mean that you 
feel the lack of engagement is a result of a previous lack of pressure?  
I have to admit that runs counter to my own sense---I thought there was 
already significant social pressure on Bitcoin Core contributors to work 
on CTV (and now CSFS); I wouldn't expect more pressure to achieve new 
results; rather, I'd expect more pressure to create more frustration on 
all sides.

Alternatively, if you feel like the lack of engagement is a result of 
some other condition, I would be curious to learn of that condition and 
learn why you thought an open letter (with what comes across as an 
ultimatum) would help address it.

Thanks,

-Dave

-- 
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/195051b7c393b9a28727e87647ac002b%40dtrt.org.

Re: [bitcoindev] CTV + CSFS: a letter

[Andrew Poelstra]

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

Le Mon, Jun 09, 2025 at 04:08:21PM -1000, David A. Harding a écrit :
> 
> Why do you think nobody in Core wants to engage at all with consensus
> changes (or, at least, specifically the proposals for CTV & CSFS)?
>

Because everybody actively working on Core has a project that, while
interesting and useful, does not affect users or the network in any
visible way. Over the years there has been a ton of work refactoring
the project into multiple libraries, rewriting the logic behind the
RPC interface and help text, upgrading to new C++ versions, etc.,
and yet if you want to mine from your local node on a local miner
today you need to run Sjors' personal fork of the project plus two
other daemons.

I'm being a bit unfair here -- over the same period there has been a
ton of critical infrastructure work on transaction relay, descriptor
wallets and mempool unification. Some things, like TRUC, even change
relay behavior on the network. But these are still things that no
ordinary user could articulate well enough to complain about.

This is understandable -- I also don't want to deal with the kind of
BS where making simple obvious mempool optimizations leads to Twitter
brigading and funded FUD campaigns. (Let alone something like the segwit
FUD campaign which was much larger and more professional.) And of
course, consensus changes requires large-scale public engagement; these
changes are not "luck of the draw" "hope your change doesn't get linked
on twitter" kinda things.

But the result, when everybody feels this way, is a lack of engagement
from the project as a whole.

Complicating matters is the fact that it's quite hard to contribute
things to Bitcoin Core -- it is hard to get reviews, when you can get
them they're slow, you need to spend months or years rebasing over the
codebase churn, etc. These problems are well-known. So it's hard to
onboard new people who want to push on more-visible things.

> The usual purpose of an open letter is to generate public pressure against
> the target (otherwise, if you didn't want to generate public pressure, you
> would send a private letter).

There isn't really any place to send a "private" letter. For most
open-source projects I could just file a discussion on their Github
repo, which would be unnoticed and unread by anyone else. Core does not
have that privilege.

There are in-person meetups a few times a year but for (happy) family
reasons I've been unable to attend, and won't be able to for the next
few years at least.

And of course I could email specific developers personally, but there
are no individuals that it makes sense to target, because this isn't an
individual problem. It's an incentive problem.

> Does that mean that you feel the lack of
> engagement is a result of a previous lack of pressure?  I have to admit that
> runs counter to my own sense---I thought there was already significant
> social pressure on Bitcoin Core contributors to work on CTV (and now CSFS);
> I wouldn't expect more pressure to achieve new results; rather, I'd expect
> more pressure to create more frustration on all sides.
>

I think that logistically there isn't any non-public medium that would
work. Maybe solving this would also solve the incentive problems around
making big changes!

I spent a while deliberating about whether signing onto an open letter
would just cause flamewars and "more pressure" -- especially since I'm
probably closer to Core development than any of the other signers, and
because its specific technical demand (CTV + CSFS) is not even something
I feel strongly about.

My goal was to start exactly this discussion, by talking about the role
Core plays in this ecosystem and pointing to (in my view) the incentive
problems that are getting in the way of that role.

> Alternatively, if you feel like the lack of engagement is a result of some
> other condition, I would be curious to learn of that condition and learn why
> you thought an open letter (with what comes across as an ultimatum) would
> help address it.
>

I apologize if it comes off as an ultimatum -- it has a timeline, but
one for a "respectful ask" for "review and integration" and no specified
consquences (I'm not even sure what consequences would look like ...
perhaps a fork of Core? I can say that I personally would never go along
with a consensus-changing fork of Core, barring some extreme event like
outright abandonment of the project.)

-- 
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster

-- 
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/aEgxuiy4dUo8sNkY%40mail.wpsoftware.net.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoindev] CTV + CSFS: a letter

[James O'Beirne]

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

Hi Dave,

> Why do you think nobody in Core wants to engage at all with consensus
> changes (or, at least, specifically the proposals for CTV & CSFS)?

For evidence of this, we need look no further than what the regulars of
the project themselves are saying. Mike Schmidt published the results of
the 2024 year-end Core contributors survey, and the aggregated answers
to "goals/priorities for 2025" were (https://archive.is/M8bln):

> - Cluster mempool completion and deployment +9
> - Enhanced wallet functionality +9
> - Testing infrastructure improvements +8
> - Security hardening initiatives +2
> - P2P layer improvements +2
> - Build system modernization +1

The "highlights from 2024" were also revealing
(https://archive.is/YNtcP). On both lists, questions of script
functionality or softforks are nowhere to be found, and this is
consistent with my personal experience in the project.

Another fact ready at hand is that while Core participants have dished
out a lot of soft, negative feedback about various proposals, or put
forth lofty posts about proposals of their own with no code (e.g. GSR,
TLUV),
they have written no code toward any of the workable proposals under
consideration. The single exception to this is instagibbs, who has
generated (valuable) code contributions toward VAULT, APO, and CSFS.

All prototyping and proposal construction have been done almost
exclusively outside of Core for the last 5 years.

---

More anecdotally, back when I was a regular (<2024) and casually talked
with some of the maintainers privately in Signal, there was open ridicule
for
developers (myself included) who would open pull requests related to
precursors for possible softforks.

As of just a few months ago, in a private Core signal group Antoine
Poinsot joked (presumably?) that if contributors simply let the recent
CHECKTEMPLATEVERIFY pull request[0] go unmoderated for a
week, the repo could close it on grounds of spam.

[0]: https://github.com/bitcoin/bitcoin/pull/31989

The message verbatim reads:

> Antoine Poinsot: At this point we could even just suspend moderation,
> all mute this thread, come back to the firehose in a week and have
> enough ground to close the PR.

Most attendees from the last CoreDev event should be able to attest to the
faithfulness of this transcript.

This instance, in conjunction with the fact that Poinsot is probably the
most active Core regular (of 2 or 3) actively engaged in covenants
discussions now, is not grounds for optimism for me personally.

This is all to say nothing of the reception that Jeremy Rubin was given
by Core regulars during 2020-2024.

Project internals aside, the plain fact is that despite changes that
have been stable for many years and significant community support, the
Core project does not feel meaningfully closer to merging even precurors
(e.g. regtest-only implementation) to improvements in script
functionality today than it did 3 years ago.

The more senior contributors in Core used to swap emails about
graftroot and APO (circa 2018), but now the major output from the
project seems to concern itself with policy, mempool design, performance
optimization, build systems -- areas that are much more permanently
malleable and (while important) are ultimately less impactful than
consensus changes.

From the standpoint of an informed outsider, it matters not so much
*why* there hasn't been progress, but simply that there hasn't been.

It doesn't really matter where the blame for this lays. What
does matter is addressing it. In my view, clearly broadcasting a
widespread desire among technical stakeholders to see a shift in focus
on the part of the de facto monopoly project seems like a necessary step
for "outsiders" of the project who are concerned about the lack of
progress.


> The usual purpose of an open letter is to generate public pressure
> against the target (otherwise, if you didn't want to generate public
> pressure, you would send a private letter).

I think there's somewhat of an excluded middle here.

While there could be many reasons for this letter, I would guess that
one of the most widely shared among the co-signers is that a public
letter of this sort creates the opportunity for a technical Schelling
point around the proposal. It demonstrates publicly and in one place
that there is considerable support among the technical bitcoin
community, and it creates a single "working draft" that can be built
around.

Many of the signers are builders capable of evaluating the proposals,
but don't necessarily have the time to opine on Delving threads or write
prototypes because they are, well, building things for actual end use.

This letter gives them a substrate to express an informed technical view
without having to construct from whole cloth a way to do that. As we all
know this takes time and is, in the case of bitcoin, fraught with social
peril.

So one of the core functions of the letter is as a single way that
engineers can demonstrate a unified agreement on a plausible
next step, and the letter exists as a public artifact of that consensus.
My own thinking was that such a unified statement would be a valuable
signal for Core contributors, indicating that a lot of the ecosystem is
serious about these changes. This creates a kind of "pressure" perhaps,
but it's the same kind of "pressure" that is created when consumers
demonstrate to a company that there's demand for a product.

The letter serves a few functions, but this optimistic one is
likely the most widely shared.

All that said, one of my personal goals in the letter, not shared by all
co-signers but likely many, is to clearly indicate dissatisfaction with
the observable status quo as of the last few years.

A few people who have suggested "if that's the case, instead of a letter
why not just release an activation client?" I think we all know how that
would have been received. This letter is a less drastic move that both
unambiguously signals dissatisfaction but stops short of acting rashly
and ineffectively.

Warm regards,
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%2B0M2PPYOAuWNt9EFWBXGspkZ3xDXKb9Tm7MW8RO3X0aA%40mail.gmail.com.

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

Re: [bitcoindev] CTV + CSFS: a letter

[Sjors Provoost]

Hi James,

From both your and Andrew's mail we can distill a relevant factor: pretty much everyone who is excited about (feature) soft forks is not working on Bitcoin Core.

A few, such as yourself and Jeremy, were in the past but stopped doing so.

Although trying to persuade more people inside the project to review and further develop these proposals is useful - methods and tone tbd - also consider the opposite: convince more people who want these changes to start contributing to Bitcoin Core.

Perhaps there should be grants specifically for people working on this, because as you point out it's quite the uphill battle and rebase hell. That's even true for proposals with broad support inside the project, just ask Antoine Poinsot what experience led him to (temporarily) rage-close BIP54 [0].  

There are of course two downsides to that approach:

1. It takes years to ramp up. The best time to plant a tree is ten years ago. But it's been six years and multiple developers could have been ramped up by now. To be fair, grant budgets were pretty tight until only two years ago.[1]

2. As a new developer becomes familiar with the project, they develop their own list of priorities which may no longer include the soft fork they were originally excited about.

Both can be overcome and if the industry is serious about these proposals they should allocate such resources. This sounds like a cop-out:

> Many of the signers are builders capable of evaluating the proposals,
but don't necessarily have the time to opine on Delving threads or write
prototypes because they are, well, building things for actual end use.

With grants one does have to careful to not create an incentive where the new developer has to achieve soft fork activation at all cost. Too much of that will lead to massive friction and burn them out very quickly, as Mike Hearn, Gavin Andresen and Jeff Garzik can probably attest. I don't how to best encode "don't put too much ego in your proposal, it will be your undoing" in a grant contract.

---

Let me also speak a bit to my own motivation. Vaults appear to be the only feature enabled by the proposal that I personally find important enough to work on.

Bear in mind that my main priority in these six months is getting Stratum v2 readiness in v30 [2], in order to end the situation Poelstra described, and to ensure Bitcoin Core is no longer a bottleneck:

> and yet if you want to mine from your local node on a local miner
today you need to run Sjors' personal fork of the project plus two
other daemons.

Congestion control seems highly premature, Lightning works well enough for me, which makes me less motivated to look into LN-Symmetry - though I'm happy to test a working demo. I don't see an urgent need for alternative L2 systems.

Up until quite recently it seemed to me that the momentum for vaults was in OP_VAULT, which in turn would require OP_CTV.  But a single purpose op code is not ideal, so this project didn't seem to be going anywhere.

I only realised yesterday that the vaults enabled by just CTV are much more ergonomic than I assumed, so I'll (continue to) look into CTV from that perspective [4].

A fully fleshed out shielded CSV demo is another thing that would motivate me to review things. That actually helps with a very serious problem: privacy.

That's why I would prefer  a more powerful soft fork, conditional on people doing a proper analysis on the MeVil issue - instead of the current strategy of avoiding it. I'd get my vaults, and the BitVM folks can have at it, hopefully with less crazy transactions.

Or is CTV + CSFS enough for that? My naive impression is that CCV + CAT + 64 bit arithmetic would be much more useful there, allowing a bridge without BitVM. But maybe it's a good enough start? I suppose Poelstra co-signed for a reason :-)

Conversely, I don't oppose CTV + CSFS; I haven't seen an argument that they're harmful. Since there's little MeVil potential, I could also imagine other developers carefully developing and rolling out these changes. I would just keep an eye on the process.

What I  _would_ oppose is a Python based alternative implementation and activation client like co-signer Paul Sztorc proposed.[3]

Cheers,

Sjors

[0] https://github.com/bitcoin/bips/pull/1800#issuecomment-2836126414
[1] https://opensats.org/blog/opensats-receives-additional-funding-of-dollar10m-from-startsmall
[2] https://github.com/bitcoin/bitcoin/issues/31098  
[3] https://www.youtube.com/watch?v=ImUCulfr1cE
[4] https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766


-- 
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/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D%40sprovoost.nl.

Re: [bitcoindev] CTV + CSFS: a letter

[Melvin Carvalho]

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

út 10. 6. 2025 v 1:11 odesílatel Andrew Poelstra <apoelstra@wpsoftware.net>
napsal:

> Le Mon, Jun 09, 2025 at 04:40:52AM -0700, James O'Beirne a écrit :
> > 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.
> >
>
> Hi all,
>
>
> James, thanks for posting the letter. Matt, Antoine -- thanks for
> replying quickly and respectfully even though you disagree with its
> contents. Let me try to clarify my stance and why I signed onto the
> letter.
>
> First, the specific choice of CTV + CSFS would not be my first choice
> on technical grounds. But what I'd like to see is something that is
> technically "good enough" to enable vaults and some new script usecases,
> while avoiding things that are politically toxic (which seems to be
> pretty-much everything, but maybe right now does not include CTV+CSFS?).
>
> So any arguments about CTV+CSFS on the technical merits I think are
> great and within the purview of "review and integration" that the letter
> talks about. (The word "final" I think is too strong and in retrospect
> I think we should've dropped it. But it's super difficult when writing
> these things to identify which specific points of language need to be
> changed.)
>
>
> Second, regarding the ultimatum language -- it was quite difficult to
> strike a balance between "Core consists of volunteers working on their
> on projects, with no obligation to anybody, and certainly no obligation
> to drive forward consensus changes" and "this is a letter that says
> nothing substantial at all".
>
> The message that I want to communicate is: Bitcoin Core, like many
> stakeholders, can veto any consensus changes because there will never be
> a large enough contigent of the Bitcoin community confident to rush in
> where angels dare to tread. But furthermore, if nobody in Core wants to
> engage at all with consensus changes, then the result is effectively the
> same as a veto.
>
> Therefore, if we want to see an increase in script expressivity, somebody
> on the Core team needs to help champion it. (There's no one in particular
> I imagine this "somebody" to be, and I suppose you could accuse me of
> hypocrisy since I'm not volunteering myself, even though I have the
> social and technical knowledge to help. It could be, and probably would
> have to be, somebody who isn't currently active on Core. But it needs to
> be somebody willing and able to work within the Core review process, to
> deal with ongoing rebases, etc.)
>
>
> Third, I really really hope that this letter does not lead to further
> brigading or twitter fights or whatever bleeding into the Github repo.
> (This is the one point where I think that my fellow cosigners agree with
> me fully.) But on the other hand, I don't think that I personally should
> shy away from discussion to mitigate that risk; it needs to be mitigated
> by more agressive moderation or by higher barriers to entry for people
> posting on Core PRs.
>


Andrew, would you agree with this premise?

Bitcoin changes must be demonstrably proven safe, needed, and wanted before
adoption.  Proposers bear the burden, not the community.  If the benefit
doesn't demonstrably outweigh the risk, the answer is simple: don't fork
the rules.


>
>
>
> Best
> Andrew
>
>
>
>
> --
> Andrew Poelstra
> Director, Blockstream Research
> Email: apoelstra at wpsoftware.net
> Web:   https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
>     -Justin Lewis-Webster
>
> --
> 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/aEdoIvOgNNtT6L4s%40mail.wpsoftware.net
> .
>

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

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

Re: [bitcoindev] CTV + CSFS: a letter

[Greg Sanders]

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


Sorry, this got very long at least for my standards.

I'd like to start off by saying I believe that Bitcoin is in good technical 
hands regardless of how this shakes out. Good things take time and we've 
learned a lot; let's continue doing so.

Before I dive into what I think needs to be answered for this proposal to 
move forward, I'd like to respond to language in the letter to make sure 
we're on a common understanding of the asks being given here.

> 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 is the meat of the post. This seemingly dictates inclusion for 
activation as a fait accompli. Is this intended? The most generous 
interpretation is that it's an ask for rigorous review, with the explicit 
intention that if there is broad technical consensus to activate, that 
broader communication to non-technical world + activation discussions 
occur. I'd like to think this this is especially a call for those who have 
not spoken up, including those who have done the homework yet conceptually 
disagree?

What efforts will be done by proponents to gather that feedback and make it 
public?

Each co-signer should consider what feedback could be received that would 
demonstrate lack of technical consensus. I think it's plain that there 
isn't at least 100% excitement in the technical community for the proposal. 
How much of this lack of enthusiasm stems from inattention vs outright 
opposition? 

> six months

What happens if this time runs out? Is this just an ask to have people take 
a look within a "few months" and continue/cease work after depending on 
results?

# Feedback on Effort

I grouped my specific feedback as larger conceptual concerns, specification 
concerns, and deployment concerns. They don't need to be answered inline 
here at this specific venue, but this is a synthesis of my hesitation about 
the current effort, hopefully with some concrete actions that can be taken.

For sake of discussion:
"CTV" means "next tx" commitment capability, not BIP119 per se
"TXHASH" means CTV with many knobs for app devs to choose what to commit to
"CSFS" means what's on the tin (less wiggle room here for changes)

## Larger conceptual concern:

Given all the things we've learned over the lifetime of BIP119 and the 
prior iterations, we need to consider "why here and not there". What's a 
good stopping point for adding functionality to Bitcoin Script, when we 
have essentially infinitely combinations possible and different strategies?

My mental model of where we should stop in terms of capabilities comes in 
the form of: 

"Why here and not there"?
 - Why not just CTV?
 - Why CTV + CSFS?
 - Why not TXHASH + CSFS?
 - Why not bucket of opcodes? "swiss army knife" approach

"MEVil" is one type of objection to generalized Bitcoin script 
introspection. CTV+CSFS is not known to appreciably increase MEVil 
potential. For the sake of argument, let's assume this dimension doesn't 
matter, due to a mixture in technical/market realities, or ColliderVM is 
deployed, or the deployment of based rollups on Bitcoin without any 
softforks. In some of those cases we should deploy anti-MEV technology 
regardless, but let's set that aside.

Everyone should consider these on their own but stating my own view to 
start the conversation:

Why not just CTV? I think there is general agreement that CTV alone was 
insufficiently exciting to enough of the technical community to be deployed 
on its own. There are some cool usages without, but the complementary 
nature of a straight forward CSFS capability is too much to overlook, 
increasing the flagship use-cases substantially.

Why not TXHASH+CSFS? If the cost is a year of concentrated development to 
do something better, we should just do it. We could easily as a community 
decide that TXHASH (with CTV capabilities being baked in as a trivial 
default mode thereof) is the thing we actually want and easily get the 
design finalized within that timeframe. With TXHASH+CSFS we can let app 
developers decide what they find important, versus the opinionated CTV 
default, whatever that is.

Note that I'm not totally convinced by this argument in either direction. 
Once we have TXHASH, there's really no reason to not have CAT (that's very 
small too!), maybe big num math, perhaps direct introspection. Maybe 
bllish, simplicity, or GSR? The community would have to agree on a stopping 
point, and that seems like it could be difficult to do in a 
short-in-year-terms timeline.

Why not bucket of opcodes? Same arguments apply on slippery slope but 
moreso. There's no clear stopping point, turning it into a giant research 
and engineering project, even if it's a good idea to start working on it 
now.

## Specification concerns:

1. Why not commit to annex? I had considered future annex relay as 
problematic for rolling out BIP119 due to its lack of commitment to the 
annex field. Committing or not are both reasonable depending on usage. With 
https://github.com/bitcoin/bitcoin/pull/32453 it at least won't impede 
annex relay efforts unduly, so maybe this can be punted and CTV sticks 
closer to it's minimalistic txid-stable design goal. Bringing this up 
because few people seem to have considered this historically.

2. Legacy script support is not technically necessary for the capabilities 
we desire. It considerably increases review surface for no known capability 
gain and no known savings for protocols. Legacy scripting should not be 
modified lightly, and if there's no strong motivation, it should be 
abandoned in favor of solutions that don't touch it. See more discussion in 
that direction here: 
https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/75

2. BIP119 committing to other prevouts very indirectly is a surprising 
anti-feature: 
https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591

This feature is proported to make specific BitVM constructions trustless in 
one respect, instead of the 1-of-n trust assumption held. This is extremely 
surprising, and as can be seen in the thread extremely brittle and ugly. 
BIP119 activated alone seemingly incentivizes very non-standard scriptSigs 
on legacy scripting, rather than directly offering the functionality 
desired. This is a bad sign which either means we should ban it outright by 
f.e. requiring scriptSigs to be blank, or take another long hard look at 
TXHASH to give app devs tools they actually want such as TXHASH.

What other surprising capabilities lurk in BIP119 that would incentivize 
deranged usage like this? Maybe nothing? Perhaps it's hubris to predict it 
and we should just do TXHASH? Maybe this hack is not a big deal and I 
shouldn't be physically repulsed by having to carve out a standardness rule 
for it?

## Concrete Deployment concerns:

1. Summarize technical community objections and adequately address them in 
a single discoverable location. I do not believe this has been done 
adequately up until now.

2. Specification feedback fully addressed and discoverable in a single 
location.

3. Flagship PoCs: At a minimum I would hope for some level of LN-Symmetry 
PoC, and or perhaps proving out hArk(or Erk), and make sure they are 
re-validated on whatever the final spec would end up being. If we want to 
draw some lessons on taproot activation it should be that validation should 
be done throughout the lifetime of the proposal, not early and then only 
after activation.

I'm hopeful on this front but 6 months to get things like this done in 
addition to everything else seems very short.

4. Second consensus implementation: It's important to validate the BIPs and 
gather more design feedback before finality of spec. Again, let's learn 
some lessons from past mistakes. Can btcd get a branch up and running that 
matches the specs and bitcoind?
On Tuesday, June 10, 2025 at 5:52:27 AM UTC-4 Melvin Carvalho wrote:

>
>
> út 10. 6. 2025 v 1:11 odesílatel Andrew Poelstra <apoe...@wpsoftware.net> 
> napsal:
>
>> Le Mon, Jun 09, 2025 at 04:40:52AM -0700, James O'Beirne a écrit :
>> > 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.
>> >
>>
>> Hi all,
>>
>>
>> James, thanks for posting the letter. Matt, Antoine -- thanks for
>> replying quickly and respectfully even though you disagree with its
>> contents. Let me try to clarify my stance and why I signed onto the
>> letter.
>>
>> First, the specific choice of CTV + CSFS would not be my first choice
>> on technical grounds. But what I'd like to see is something that is
>> technically "good enough" to enable vaults and some new script usecases,
>> while avoiding things that are politically toxic (which seems to be
>> pretty-much everything, but maybe right now does not include CTV+CSFS?).
>>
>> So any arguments about CTV+CSFS on the technical merits I think are
>> great and within the purview of "review and integration" that the letter
>> talks about. (The word "final" I think is too strong and in retrospect
>> I think we should've dropped it. But it's super difficult when writing
>> these things to identify which specific points of language need to be
>> changed.)
>>
>>
>> Second, regarding the ultimatum language -- it was quite difficult to
>> strike a balance between "Core consists of volunteers working on their
>> on projects, with no obligation to anybody, and certainly no obligation
>> to drive forward consensus changes" and "this is a letter that says
>> nothing substantial at all".
>>
>> The message that I want to communicate is: Bitcoin Core, like many
>> stakeholders, can veto any consensus changes because there will never be
>> a large enough contigent of the Bitcoin community confident to rush in
>> where angels dare to tread. But furthermore, if nobody in Core wants to
>> engage at all with consensus changes, then the result is effectively the
>> same as a veto.
>>
>> Therefore, if we want to see an increase in script expressivity, somebody
>> on the Core team needs to help champion it. (There's no one in particular
>> I imagine this "somebody" to be, and I suppose you could accuse me of
>> hypocrisy since I'm not volunteering myself, even though I have the
>> social and technical knowledge to help. It could be, and probably would
>> have to be, somebody who isn't currently active on Core. But it needs to
>> be somebody willing and able to work within the Core review process, to
>> deal with ongoing rebases, etc.)
>>
>>
>> Third, I really really hope that this letter does not lead to further
>> brigading or twitter fights or whatever bleeding into the Github repo.
>> (This is the one point where I think that my fellow cosigners agree with
>> me fully.) But on the other hand, I don't think that I personally should
>> shy away from discussion to mitigate that risk; it needs to be mitigated
>> by more agressive moderation or by higher barriers to entry for people
>> posting on Core PRs.
>>
>
>
> Andrew, would you agree with this premise? 
>
> Bitcoin changes must be demonstrably proven safe, needed, and wanted 
> before adoption.  Proposers bear the burden, not the community.  If the 
> benefit doesn't demonstrably outweigh the risk, the answer is simple: don't 
> fork the rules.
>  
>
>>
>>
>>
>> Best
>> Andrew
>>
>>
>>
>>
>> -- 
>> Andrew Poelstra
>> Director, Blockstream Research
>> Email: apoelstra at wpsoftware.net
>> Web:   https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>>     -Justin Lewis-Webster
>>
>> -- 
>> 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/aEdoIvOgNNtT6L4s%40mail.wpsoftware.net
>> .
>>
>

-- 
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/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn%40googlegroups.com.

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