CTV + CSFS: a letter

[James O'Beirne]

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)

[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

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



--
Michael Folkson
Personal email: michael...@gmail.com

[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

> --
> 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 <mailto:bitcoindev+...@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>.

[James O'Beirne]

On Mon, Jun 9, 2025 at 9:51 AM Matt Corallo <lf-l...@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

[James O'Beirne]

On Mon, Jun 9, 2025 at 8:51 AM Michael Folkson <michael...@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]

> 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

[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-l...@mattcorallo.com <mailto:lf-
> li...@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

[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

[Antoine Poinsot]

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

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

[/dev /fd0]

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

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

[Andrew Poelstra]

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

[Paul Sztorc]

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

[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

[Melvin Carvalho]

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

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.

[Greg Sanders]

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?

[Andrew Poelstra]

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

[James O'Beirne]

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

[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

[Antoine Poinsot]

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

This is incorrect. I am excited about potential extensions to Bitcoin's scripting capabilities. I know at least Greg Sanders and Anthony Towns have shown interest, given their substantial contributions in this area. You are showing interest too, and i know others are interested. This is plenty of individuals that are both interested in "feature" soft forks and contributing to the Bitcoin Core project.

I won't take the bait into responding to people breaking Chatham House rule to steer political drama. But the reason for the lack of progress of these proposals and others is not to be found with Core contributors.

> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D%40sprovoost.nl.

[Matt Corallo]

I don't think this is a fair characterization in the slightest. Yes, many people who contribute to
Bitcoin Core are not currently spending their time working on consensus changes, but that doesn't
mean they didn't pick to work on something that they think is the highest ROI on their time for the
bitcoin network as a whole.

The relay changes you mention but sweep under the rug are a critical improvement to the security
model and usability of lightning, a widely-deployed and now highly utilized critical piece of
bitcoin (Cash App's public numbers from the Vegas conference indicate its about 25% of their
withdraw volume by count!).

While many of the letter signatories may think that that isn't the right use of time, or the best
way to improve Bitcoin, I don't think its a fair conclusion to claim that they're somehow wrong,
rather than simply of a different opinion.

Its also probably fair that many developers don't really *want* to work on consensus changes because
of the risk of Drama, but that's clearly not universal, given Antoine's work to pick up and tweak
the Great Consensus Cleanup. Clearly some Bitcoin Core contributors think that working on consensus
changes is the best use of their time, just not the ones that the letter signatories happen to think
are the important ones.

Of course sign-on letters do little to reduce the impact of Drama, only contribute to it :(

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

If its an incentive problem, though, sending a vaguely-threatening letter giving a six-month
ultimatum is all the more likely to drive the incentives in the wrong direction, not the right one.
Asking individuals why they, personally, are not currently working towards script expansion changes
is probably much more illuminating, or asking "what would it take to convince you to work on these
kinds of changes".

In my experience, there is interest from various Bitcoin Core contributors to spend time on this,
but four-year projects like mempool policy have some way to go towards their conclusion and people
like to see things through :).

The fact that several companies are working to build and deploy Ark-based payment systems is also a
large part of that - having a concrete application where the developers see substantial gains (which
can be independently evaluated, at least once things are up and running, which as I understand it
will be soon) with specific consensus changes is a strong motivator. Previous attempts at getting
CTV activated largely (in my experience) failed to get people excited because the demonstrated
use-cases for CTV by itself did not feel super compelling.

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

Conferences, individual emails, signal messages are all options that exist? I'm kinda confused by
this comment, honestly. Yea, there's no great way to "address all of Bitcoin Core" at once, but that
doesn't mean most of the most prolific contributors don't go to regular conferences, meetups, and
aren't responsive to personal messages (at least in some cases).

I imagine, maybe wrongly, but I imagine that nearly every substantial Bitcoin Core contributor is at
least two conferences a year, and they're usually speakers so their names are on the websites of the
conferences.

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

Fair enough. There are apparently differing views by other letter-signers on the meaning of the "six
month" timeline :).

Matt

[James O'Beirne]

Greg,

Thanks for your thoughtful reply. I appreciate how thoroughly you've
considered this stuff, and while I have objections to certain
characterizations you make in the post, it is in general a strong
contribution to the discussion.

Replies inline:

> I think there is general agreement that CTV alone was insufficiently
> exciting to enough of the technical community to be deployed on its
> own.

I don't think that's an accurate read; there is a fairly large
contingent of technical people who would have happily deployed CTV on
its own. We never got an explicit count of how large that group is, but
I can say anecdotally that many signers of this letter would likely hold
that view.

The CTV-on-its-own applications (vaults -- both as "ingredient" and
"full solution," DLC improvements, trustless mining payouts, ...) are
compelling enough to many. And over time it's become obvious that having
a consensus primitive that allows commitment to spend by a predetermined
sequence of transactions is a necessary component of the complete
realization of many layer twos. BIP-119 is just the simplest formation
of this.

> Why not TXHASH+CSFS? If the cost is a year of concentrated development
> to do something better, we should just do it.

I think the unit of a "year of engineering time" rarely makes sense,
especially in an open source bitcoin context, and especially when we're
talking about bitcoin consensus changes.

We don't know what kind of delays a "year of concentrated development"
will induce, or what kind of environment the ecosystem will find itself
in when the change is finally "ready."

The appealing part of CTV+CSFS is that the changes are already baked,
and have been unchanged for years. Even with your concerns about legacy
scriptSig usage, the reality is that if we merged the changes as
proposed, they would work well and safely for anything resembling an
advertised use.

> With TXHASH+CSFS we can let app developers decide what they find
> important, versus the opinionated CTV default, whatever that is.

The "opinionated CTV default" is simply the most basic way to generate a
commitment to a future sequence of transactions without malleability.
"Whatever it is" is clearly defined in the BIP and implementation.

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

For those who don't recall, BIP-341 (which introduced the annex) writes:

> Until the meaning of this field is defined by another softfork, users
> SHOULD NOT include annex in transactions, or it may lead to PERMANENT
> FUND LOSS.

As you point out, right now BIP-119 does not commit to the annex. If the
annex is ever given meaning via consensus change, and if for some
reason, some use needs a commitment to its contents in CTV, we can
upgrade CTV in any number of different ways (longer CTV arg, new opcode,
...) to accomodate this when we have a specific use.

In the meantime, CTV not committing to the annex does not make it any
less useful or any more of a future liability.

But another, maybe better, reason not to commit to the annex within the
CTV hash is that it would then constrain the possible purpose of the
annex itself to information that can be known ahead of spend time.

The annex should first figure out its use -- timeline indeterminate on
that one -- before CTV does. Once that happens, this can be handled
easily with the various upgrade hooks that script now has.


> [Legacy CTV use] considerably increases review surface for no known

> capability gain and no known savings for protocols.

I think this is a pretty hefty mischaracterization taken for granted.
While it "increases review surface" in that we have to consider the
legacy case, I think it's much less a task than you're making it out to
be.

Supposed review burden aside, there _are_ known savings for protocols;
vaults may ultimately want to send directly to bare CTV scripts, saving
8vB (= 32WU) for each output.

Congestion control trees, which have various known and possible uses in
L2s, trustless mining payouts[0], and potential future uses like batched
exchange withdrawals, save a multiple of 8vB that grows _exponentially_
at each level of the tree[1].

[0]: https://delvingbitcoin.org/t/scaling-noncustodial-mining-payouts-with-ctv
[1]: https://utxos.org/uses/scaling/

We get the option of all those future savings for free simply by not
touching the existing (reviewed) proposal, which has been in its current
form for years. You personally may not be convinced that bare congestion
control will ever be used, but some disagree, and even more at least
believe we should allow for the possibility when the marginal cost is so
little.

> BIP119 committing to other prevouts very indirectly is a surprising

> anti-feature [...]

> This feature is proported to make specific BitVM constructions trustless

This isn't a claimed "feature" of BIP-119 - it's a non-obvious,
off-label use that was pretty quickly found to have problems.

CTV commits to scriptSigs (if they exist) in order to avoid txid
malleability when used with other legacy inputs (as it says in
BIP-119[2]). This is the only claimed purpose of the commitment.

[2]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committing-to-the-scriptsigs-hash

That the proposed BitVM use described in the Delving thread is broken is
sort of like saying we shouldn't have SIGHASH_SINGLE because trying to
slam together input/output pairs with SIGHASH_SINGLE|ANYONECANPAY for a
coinjoin scheme inadvertently introduces pinning vectors.

> BIP119 activated alone seemingly incentivizes very non-standard
> scriptSigs on legacy scripting, rather than directly offering the
> functionality desired

This is not an advertised use-case (or even one that works), so I'm not
sure how BIP-119 is incentivizing anything other than the many
advertised uses that it's been aimed at.

To my knowledge there isn't a proposal that actually satisfies this
particular use without stepping up the implementation complexity by an
order of magnitude, as in the case of TXHASH. See again: upgrade hooks
when we finalize use-case.

> What other surprising capabilities lurk in BIP119 that would
> incentivize deranged usage like this? Maybe nothing?

This reads like a tabloid headline; you could make similar arguments
about any possible proposal on the table, except none of the other ones
have been scrutinized for as long as BIP-119 has, and none of the other
ones have sat with a 5.3 BTC bounty on them for a few years[3].

I'm not saying you're claiming this, but to think that a more complex
proposal like TXHASH (or variant) is going to have fewer surprising
cases than something relatively constrained like CTV is not realistic.

[3]: https://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af

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

It is this kind of message and thinking that's brought us to this point.
Fractalized delays on things that haven't really changed in years.

The amount you've written in this post and the concerns you've raised
might make the reader think there are a number of fundamental, scary
uncertainties with BIP-119 - but in actuality, they're minor points that
have been addressed in the past elsewhere, although admittedly not in a
single place.

The reality is that these changes could be merged as-is and there would
be no negative externalities to bitcoin. Quite the opposite.

I'm certainly not opposed to making changes where merited. But any
changes made are going to set back the clock on deployment and
activation as they need to be propagated through the various layers of
technical review. We should only do this for real, good reasons.


Warm regards,
James

[Greg Sanders]

Just noting that the "what is the ultimatum" section is still a standing question, though I appreciate Andrew's e-mails and am taking that as a partial answer that he at least wants everyone to take a serious look at the proposal. 

> I don't think that's an accurate read; there is a fairly large
contingent of technical people who would have happily deployed CTV on its own

I presumed they were being bundled together because of complementary capabilities to convince people over the previously failed CTV-only activation attempts. I don't want to do crowd estimation but it seems clear to me there is higher excitement for this one.

> In the meantime, CTV not committing to the annex does not make it any

less useful or any more of a future liability.

It clearly can be a liability if the relative utility of CTV is damaged by a possible future change, even non-consensus ones, some of which are already being deployed with non-zero miner support such as https://x.com/PortlandHODL/status/1921350395424563572 . This could have led to legitimate usage of CTV being trivially DoS'able. Good news is there are practical if not beautiful mitigations to this that don't involve annex commitment. See https://github.com/bitcoin/bitcoin/pull/32453 and https://github.com/petertodd/bitcoin/pull/10 for some relevant details.

> Supposed review burden aside, there _are_ known savings for protocols;

vaults may ultimately want to send directly to bare CTV scripts, saving
8vB (= 32WU) for each output.

I offered the "P2CTV" template for exactly this purpose, please consult the patch I wrote. There's no need to introduce more script execution to support it.

> This isn't a claimed "feature" of BIP-119 - it's a non-obvious,

off-label use that was pretty quickly found to have problems.

> To my knowledge there isn't a proposal that actually satisfies this

particular use without stepping up the implementation complexity by an
order of magnitude

The Delving thread is declaring that it's a game-changer for BitVM, to some knowledgeable people it's obviously considered a feature. If I understand correctly it literally changed Robin Linus' opinion on the proposal for CTV! From my discussions with other BitVM implementers it certainly sounds practical? Forgive me for not taking your word for it.

We shouldn't offer extremely sharp edges if there will be market demand for it, we should properly address the issue one way or another.

 > This reads like a tabloid headline; you could make similar arguments

about any possible proposal on the table, except none of the other ones
have been scrutinized for as long as BIP-119 has, and none of the other
ones have sat with a 5.3 BTC bounty on them for a few years[3].

Incentivizing frankly insane usage is a danger to a proposal. To be surprised by a now sought after use-case that abuses legacy script's deformities, nearly 5 years after the spec hasn't changed, and to ask a question on a thread about a proposal? That's tabloid thinking? Let's be serious.

> I'm not saying you're claiming this, but to think that a more complex

proposal like TXHASH (or variant) is going to have fewer surprising
cases than something relatively constrained like CTV is not realistic.

Granted, TXHASH may even introduce even *weirder* edge cases (though it would have mitigated this specific one), but a middle-ground could be offering exactly what is being desired: A way to commit to a neighbor prevout in some way. If that's the capability we want, we should design for it. If it's not, we should mitigate it by disallowing it.

> Fractalized delays on things that haven't really changed in years.

> I'm certainly not opposed to making changes where merited. But any

changes made are going to set back the clock on deployment and
activation as they need to be propagated through the various layers of
technical review. We should only do this for real, good reasons.

This letter is asking for feedback from the technical community and this is my feedback.

Undeployed BIPs that have not received any updates in years is generally not a sign of proposal health, and certainly not a foundation to reject technical advice from someone who's paid close attention. 

I reject this framing, the raising of the bar of changes to this proposal to only egregious breaks, and I obviously reject a time based ultimatum for BIP119 as-is.

I still think CTV(again in the capability sense) + CSFS are worthy of consideration, but this is a surefire way to sink it.

Greg

[James O'Beirne]

Greg,

> Just noting that the "what is the ultimatum" section is still a
> standing question

I think this is outside the scope of the letter and this discussion -
different cosigners will have different ideas about what should happen
if another 6 months goes by without a serious attempt at review and
integration. We'll cross that bridge when/if we come to it.

> I don't want to do crowd estimation but it seems clear to me there is
> higher excitement for this one.

We certainly agree there. I know I'm personally more excited about this
package than just CTV. I only meant to suggest that there are many
people who would have liked to see CTV active on its own earlier.

> It clearly can be a liability if the relative utility of CTV is
> damaged by a possible future change, even non-consensus ones, some of
> which are already being deployed with non-zero miner support such as
> https://x.com/PortlandHODL/status/1921350395424563572 .

Worth noting that Portland himself, on behalf of MARA Pool, is a signer
of the letter.

> I offered the "P2CTV" template for exactly this purpose, please
> consult the patch I wrote. There's no need to introduce more script
> execution to support it.

I assume by "more script execution" you're talking about simply allowing
the same script interpreter path that everything else uses for CTV on
legacy, as it's currently written.

Maybe others can debate about whether bumping to a new witness version
is a larger or smaller conceptual burden than just dealing with legacy.
I don't have a great sense of it. Naively it sounds workable to me, but
I still don't really agree with the premise that enabling CTV in legacy
is complicated or dangerous.

> The Delving thread is declaring that it's a game-changer for BitVM, to
> some knowledgeable people it's obviously considered a feature. If I
> understand correctly it literally changed Robin Linus' opinion on the
> proposal for CTV!

Worth noting that even after the discovery that this hack isn't a real
use for CTV, Robin still signed this letter. But I will let him speak
for himself.

> From my discussions with other BitVM implementers it certainly sounds
> practical? Forgive me for not taking your word for it.

I think we might be confused here - I'm certainly not calling BitVM
impractical, or what they were trying to do more generally. I'm just
saying that CTV might not be the appropriate tool for it, which I think
is now clear to everyone. CTV shouldn't really be blamed for this
because it was a known hack to begin with.

> A way to commit to a neighbor prevout in some way. If that's the
> capability we want, we should design for it. If it's not, we should
> mitigate it by disallowing it.

The point of this whole discussion is that scope expansion continues to
happen ad nauseam and consequently no progress is made. This can be a
separate consideration with a separate design process without harming
anything.

> I still think CTV(again in the capability sense) + CSFS are worthy of
> consideration, but this is a surefire way to sink it.

I sincerely apologize if this has been a frustrating exchange, and I
myself am far from a perfect communicator (or thinker!), but please
understand that (at least for me) the scope of this letter and
discussion are larger than BIP-119 per se. They are an attempt to
address a kind of process malfunction that is characterized by a years'
long sequence of delays brought on by ultimately minor considerations or
appeals to more ambitious designs.


Best,
James

[Antoine Riard]

Hi James,

Thanks for your post.

I think you can break the current version of CTV in the way it's currently proposed as a
NOP refurbishment (i think OP_NOP4), which makes it a legacy script.

Currently, there is a max limit of 80_000 sigops per-block (`MAX_BLOCK_SIGOPS_COST`
in `src/consensus/consensus.h). That limit is applied for all legacy, p2sh and segwit
scripts, at time of `Chainstate::ConnectBlock`:

    // GetTransactionSigOpCost counts 3 types of sigops:
    // * legacy (always)
    // * p2sh (when P2SH enabled in flags and excludes coinbase)
    // * witness (when witness enabled in flags and excludes coinbase)
    nSigOpsCost += GetTransactionSigOpCost(tx, view, flags);
    if (nSigOpsCost > MAX_BLOCK_SIGOPS_COST) {
        state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-blk-sigops", "too many sigops");
        break;
    }

This enforced limit means that any block with 80_001 signature operation
within is going to be rejected by the receiving full-node ("too-many-sigops").
where a signature operation is any opcode like a CHECKSIG or CHECKMULTISIG
(`GetSigOpCount()` in `src/script/script.h).

While signature operations is not necessarily somehting you're going to think
about when you design and deploy second-layers or contract protocol (even for
coinpool we only make assumptions of 1000-sized off-chain constructions, so
1000 sigs at max in the redeemscript), this signature operation limit is
obviously weighted in by block template construction to ensure a valid block
is generated by the network and not an insane amount of watt has been wasted.

E.g, the default block template algorithm attached in core is using this limit:

     // TODO: switch to weight-based accounting for packages instead of vsize-based accounting.
     if (nBlockWeight + WITNESS_SCALE_FACTOR * packageSize >= m_options.nBlockMaxWeight) {
         return false;
     }
     if (nBlockSigOpsCost + packageSigOpsCost >= MAX_BLOCK_SIGOPS_COST) {
         return false;
     }
     return true;

While it is well-established that many miners are running their own block
construction algorithms, one can assume this limit exist for all while it's
more unclear if they're selecting the highest feerate, *highest sigops* txn
too. This selection of highest feerate, *highest sigops* block opens the door
to an interesting exploitation for any use-cases with timelocks.

Namely, let's say you have a use-case U which is locking funds in a redeem
script S with path either alice_sig OR bob_timelock + bob_sig. Any adversary
(i.e Bob) can fulfill the sequence of blocks from current chain tip leading
up to bob_timelock to *censor* alice of redeeming the funds with high-feerate,
high-sigops junk txn.

Here a testcase on some bitcoin core 28.x branch doing so with empty CHECKMULTISIG
as they have the highest ratio of sigops accounting per unit of feerate that one
has to pay for:

https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e

A honest counterparty to the use-case U can indeed over-bid in feerate to get
her legit time-sensitive tx confirming in block template over the adversary's junk.
However, game-theory wise the counterparty is limited by the max amount of funds
locked in the shared coins U. E.g if the use-case U has a weight unit surface of 20_000
WU and an amount of 100_000 satoshis, the honest counterparty will at most burn
5 satoshis per WU.

This is a clear limit that the adversary, who is a counterparty to the locked
funds, can evaluate ahead and from then be break-even by finding N+1 use-case U
of amount U or inferior where N is the timelock duration.

While this "block sigops overflow" attacks present a lot of "maybe", most notably
what is the txn selection algorithm for block template runned by the high-hashrate
miners over the network, it's still put a wonder for any CTV use-case with a script
of the following form:

        OP_IF
                <my_little_vault_hash> OP_CTV
        OP_ELSE
                <alice_bob_their_family_aggregated_pubkey> OP_CHECKSIG
        OP_ENDIF

A simple upgrade can be to overhaul CTV design on top of a OP_SUCCESS or another
tapscript upgrade paths, as tapscripts spends do not see their signature ops
accounted in the per-block limit (BIP342 per-script sigops budget). The only
way to further exploit would be inflate the txn spending the script, which should
be correctly bounded by use-cases designers, I think.

As far as I know, this problem has always been there since the activation of
SegWit in 2017, and if I'm correct - but please don't trust, verify - the potential
exposure of any shared UTXO with timelocks and competing interest has always been
there...However, as far as I know this ill-design limit for time-sensitive use-cases
has never been really been discussed among devs circlces and my own awareness of
this problem is itself quite recent.

That's all for the "letterocracy" and the ones who're currently thinking that
covenant soft-forks are seriously technically reviewed...

The only thing I'll add I'm still eager to review in good faith _both_ your
proposal of CTV+CSFS and Poinsot's BIP54 in the future (in fine he's not personally
responsible for what I did say on the BIP repos issue) in the future.

If I'm correct on this "block sigops overflow" problem, there might be anyway
things to re-think about, at least being sure we do not introduce new issues of
this domain for current or upcoming use-cases.

Don't trust, verify.

Best,
Antoine "the evil one"
OTS hash: 3598fa5db5a6f60639f938b58d85c2b563f4ff7728061eeb166998b7280287ce

[Antoine Riard]

[Paul Sztorc]

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

I have done no such thing.

The bip300301_enforcer is in rust [0]. Furthermore, it is not an "alternative" to Core --  it must connect to Bitcoin Core, via ZMQ. (But it is an "activation client" -- of a kind.)

(Anyone who glanced at the github for 2 seconds, would see all of these things, by the way.)
(Sjors, you may be confusing my project, with Bitcoin Core, which contains python, including a siget-mining-script.)

CUSF is clever -- because it **frees** Core from the headache and responsibility of soft fork activation (which I know many people here hardly enjoy). That is why it is better -- I can activate my own thing, without bothering you all. And I don't have to "compete" with CTV to be further ahead "in line" (or whatever). So I am free to appraise CTV rationally.

We all know that Core is a meritocracy. And that every decision and sentence uttered by Core is a perfect work of divine truth -- free of all the flaws that have plagued every other organization throughout history. Lucky us! Just think, in other organizations, people sometimes allow their prejudice to color their judgement, occasionally jumping to conclusions that are incorrect -- not here though. Here it's all based on merit, baby. No need for a plan B!

Cheers,
Paul

[0] https://github.com/LayerTwo-Labs/bip300301_enforcer

[Matt Corallo]

On 6/11/25 12:50 PM, James O'Beirne wrote:
> Greg,
>
> > Just noting that the "what is the ultimatum" section is still a
> > standing question
>
> I think this is outside the scope of the letter and this discussion -
> different cosigners will have different ideas about what should happen
> if another 6 months goes by without a serious attempt at review and
> integration. We'll cross that bridge when/if we come to it.

What a wonderful way to discourage people from working with you in the strongest possible way.

Starting with vague threats is quite a strategy.

Matt

[James O'Beirne]

> Worth noting that even after the discovery that this hack isn't a real
> use for CTV, Robin still signed this letter. But I will let him speak
> for himself.

Correction and my apologies - I thought (incorrectly) based on a reading 

of the last few related Delving posts[0] that CTV wasn't actually 

usable for BitVM, but I'm being told that it is. Great news!

[0]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/23

To me this emphasizes that preserving legacy CTV is a good move now; that
way BitVM can meet its needs while more generic, ergonomic mechanisms
like TXHASH undergo design and debate.

James

[Brandon Black]

Hi Sjors,

On 2025-06-10 (Tue) at 18:56:54 +0200, Sjors Provoost wrote:
> 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.

[...]

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

You might notice that there's a strong correlation of new developers
interested in potentially making improvements to bitcoin's consensus
rules _not_ investing the years to ramp up on the project starting about
the same time that the CTV and APO proposals were abandoned.

This open letter reflects the reality that if none of the central
members of a project are working in the direction that an enthusiastic
outsider is interested in pursuing it is approximately impossible for
that outsider to ramp up on the project and reasonably hope to achieve
their goals.

I have not discussed this with other signatories to the letter, but I
suspect that a commitment to mentor and support developers working on
consensus improvements from the broader bitcoin core project would also
constitute a satisfactory response.

While we the signatories believe that CTV+CSFS is a positive direction
for consensus improvements on bitcoin, I don't think any of us would say
that it is the only possible positive consensus improvement. The primary
thrust of this letter is that consensus improvements should be
prioritized alongside other work on bitcoin core. In an environment
where consensus improvements were given equal billing to relay, p2p,
build system, refactoring and other current project priorities this
letter would never have been authored, signed, nor published.

Fond regards,

--Brandon

[Peter Todd]

On Tue, Jun 10, 2025 at 01:17:07PM -0400, Matt Corallo wrote:
> The relay changes you mention but sweep under the rug are a critical
> improvement to the security model and usability of lightning, a
> widely-deployed and now highly utilized critical piece of bitcoin (Cash
> App's public numbers from the Vegas conference indicate its about 25% of
> their withdraw volume by count!).

The relay changes are also very important to to future L2 designs too. E.g. if
Ark is to be actually be a non-custodial L2 where unilateral withdrawal
actually works, it needs to be able to avoid transaction pinning and flexibly
pay for transaction fees at least as much as Lightning does.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[Harsha Goli]

Hi Matt

> What a wonderful way to discourage people from working with you in the strongest possible way.
> 
> Starting with vague threats is quite a strategy.

Quickly chiming in here. I'm digging in heavily to the different needs and drivers of businesses and individuals in the space. I think James is being quite literal here. There is not unity on what should happen after if we reach 2026 without any progress on covenants.

Not speaking for James, but from what I've seen there is no substance or chatter regarding any such "vague threat".

Hope that clears up this unfortunate misunderstanding.

[Greg Maxwell]

Three days ago I replied[1] to this post with a simple question:   What steps have the authors taken to reduce the risks that the proposed protocol changes are free of relevant patent encumbrance? 

In any case, though it's obviously important to make sure that authors or their employers don't have any troublesome restrictions on the consensus rules, it's just as important that third parties don't have any either and much harder to gain confidence on. For prior consensus changes significant effort went into making sure that they wouldn't create an issue _in consensus rules_ since they're not-optional and it's now clear that it was quite worthwhile-- I can only imagine the climate has gotten worse.

I consider a clearance effort to be part of the required engineering for any mandatory to implement consensus rule,  since even if *you're* hidden in a cave and immune to infringement litigation many Bitcoin users are not and causing users to get it with lawsuits or fees to use Bitcoin would presumably be a tradeoff that made any change unacceptable.  (To be clear, this has always been done previously-- but not with proposals coming from outside the Bitcoin project it sounds like it may have been missed).

[1]  Aside, Somehow this message seems to have resulted in my google account being suspended and it's taken me days to recover it.  I'm told the list mods saw my message but were unable to pass it through to the list.  After recovering my account, I observed I had an offlist message from obeirne basically asking what I meant by IPR, correctly inferring I might be asking about patents, and then listing the authors.  I replied to it and had google inform me that the sender was blocking me.  :-/

On Mon, Jun 9, 2025 at 11: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

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

[James O'Beirne]

Hey Greg,

Reproducing my earlier message to you here:

> You're referring to "intellectual property rights?"
>
> The CSFS patch is derived from Elements code, which is MIT Licensed; otherwise the only authors of commits related to this proposal are:
>
> - Jeremy Rubin,
> - Brandon Black,
> - Greg Sanders, and
> - myself
>
> So I'm pretty confident we don't have any IP issues; would be trivial to get releases from each author if that's necessary.
>
> Was there something in particular you had in mind?

I never received a response, and certainly didn't block you!

Best,

James

[James O'Beirne]

Hey Antoine,

Thanks for the post. Based on my read of what you're describing

nothing in particular in your attack is specific to CTV. In your example

script, you're not making use of the template hash or OP_NOP4.

As far as I can tell, the DoS you're describing basically affects all non

witness v1 activity on bitcoin - i.e. some malicious user filling blocks

up to their sigops limit to deny other users service.

Given that probably most activity on bitcoin is not witness v1,

I don't see how this is a CTV-specific issue.

Thanks,

James

[Matt Corallo]

On 6/11/25 8:59 PM, Harsha Goli wrote:

> Quickly chiming in here. I'm digging in heavily to the different needs and drivers of businesses and
> individuals in the space. I think James is being quite literal here. There is not unity on what
> should happen after if we reach 2026 without any progress on covenants.
>
> Not speaking for James, but from what I've seen there is no substance or chatter regarding any such
> "vague threat".

I do think this highlights why sign-on letters tend to have little impact and are really quite
useless for this kind of thing: when you actually go talk to people, you come away understanding
that they have very different views on the issue at hand.

Some signers appear to have intention to release an "activation client", meanwhile when I talk to
other signers they're really just trying to encourage more focused research on things in this area.
Those are *drastically* different views, yet both are "covered" by the same letter.

Worse yet, there's now organizations signing this letter (yay NYA reprisal!), which similarly cannot
possibly be filled with people with identical views (of course organizations themselves cannot opine
on technical bitcoin decisions, individuals do, there is good reason why organizations do not have a
role within IETF, only engineers expressing their own opinions, which may benefit their organization).

Ignoring the threats in the letter, there's also a question of what the desire is - some signers
specifically want CTV + CSFS now, some signers are worried about "Bitcoin's ossification" and just
want to see progress on changes (in some cases even GCC making progress may suffice!), while yet
others want other specific things and imagine that the politics of getting their thing will be
easier once CTV + CSFS happens. These all mandate drastically different responses, yet again because
they're all bunched into one letter we cannot figure out what it is that they actually want.

Instead, and I've encouraged various people who've signed to do this, having engineers who wish to
utilize these features speak up about what, specific, tools and protocols they wish to build using
CTV + CSFS would be much more interesting. Unlike a generic "We Want Things" sign-on letter,
individual messages indicating desire to utilize features is way more compelling, not just to
overall impression of Bitcoin's consensus, but also to the individuals deciding what to do with
their time - now you can see actual real-world desires.

Matt

[James O'Beirne]

Hi Matt,

> Ignoring the threats in the letter

There are no threats in the letter, I'm not sure why you

think there are.

> there's also a question of what the desire is - some signers specifically
> want CTV + CSFS now, some signers are worried about "Bitcoin's ossification"
> and just want to see progress on changes (in some cases even GCC making
> progress may suffice!), while yet others want other specific things and
> imagine that the politics of getting their thing will be easier once CTV +
> CSFS happens. These all mandate drastically different responses, yet again
> because they're all bunched into one letter we cannot figure out what it is
> that they actually want.

As the person who coordinated the letter, I can say that this is not an
accurate characterization of the signers' intent. Everyone who signed
explicitly wants to see the imminent review, integration, and activation
planning for CTV+CSFS specifically. The letter is intentionally concise to make
sure there are no misunderstandings about that.

I spoke to each person on the original list of signatories who either did (or
didn't) sign and this was made very clear. Some people didn't sign as a result
of what the letter says.

The additional viewpoints you list may be shared by some signers, but the point
of signing the letter was to signal unambiguous support for the nearterm
integration of CTV+CSFS.

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8d158e3d-b3cc-44b6-b71b-ab2e733c047c%40mattcorallo.com.

[Matt Corallo]

On 6/12/25 2:38 PM, James O'Beirne wrote:
> Hi Matt,
>
> > Ignoring the threats in the letter
>
> There are no threats in the letter, I'm not sure why you
> think there are.
>
> > there's also a question of what the desire is - some signers specifically
> > want CTV + CSFS now, some signers are worried about "Bitcoin's ossification"
> > and just want to see progress on changes (in some cases even GCC making
> > progress may suffice!), while yet others want other specific things and
> > imagine that the politics of getting their thing will be easier once CTV +
> > CSFS happens. These all mandate drastically different responses, yet again
> > because they're all bunched into one letter we cannot figure out what it is
> > that they actually want.
>
> As the person who coordinated the letter, I can say that this is not an
> accurate characterization of the signers' intent. Everyone who signed
> explicitly wants to see the imminent review, integration, and activation
> planning for CTV+CSFS specifically. The letter is intentionally concise to make
> sure there are no misunderstandings about that.

But see this doesn't contradict what I said. Just because people think that CTV+CSFS should be
activated on some kind of accelerated timeline does not mean that they want it *because* they want
CTV+CSFS. They might (and based on my discussions some do) want it because it "prevents
ossification", or because it, in their view, unblocks progress towards something they have a more
immediate use-case for. Some, certainly, want it because they have a use for it themselves, but
others probably not so much.

Its the *why* that matters, not the ask, because, again, they all merit drastically different responses.

> I spoke to each person on the original list of signatories who either did (or
> didn't) sign and this was made very clear. Some people didn't sign as a result
> of what the letter says.
>
> The additional viewpoints you list may be shared by some signers, but the point
> of signing the letter was to signal unambiguous support for the nearterm
> integration of CTV+CSFS.

You may want to talk to Andrew Poelstra again, who on this list wrote

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

Matt

[Andrew Poelstra]

Le Thu, Jun 12, 2025 at 02:38:13PM -0400, James O'Beirne a écrit :
>
> As the person who coordinated the letter, I can say that this is not an
> accurate characterization of the signers' intent. Everyone who signed
> explicitly wants to see the imminent review, integration, and activation
> planning for CTV+CSFS specifically. The letter is intentionally concise to
> make sure there are no misunderstandings about that.
>
> I spoke to each person on the original list of signatories who either did
> (or didn't) sign and this was made very clear. Some people didn't sign as a
> result of what the letter says.
>

The letter asks Core to "prioritize the review and integration" on an
accelerated timeline, and that this will "allow" for "activation planning".

Early drafts of the letter did ask for actual integration and even
activation, but I did not sign any of those early drafts. It was not
until the language was weakened to be about priorities and planning (and
to be a "respectful ask" rather some sort of demand) that I signed on.


The letter is concise but unfortunately I think Matt is correct that it
offers a broad range of interpretations, even among the signers.

[Matt Corallo]

To be fair to James, in my (luckily rather brief) experience with Bitcoin-consensus-letter-writing,
its nearly impossible to forge a statement that everyone agrees to that is consistently interpreted.

Matt

[Jameson Lopp]

> Unlike a generic "We Want Things" sign-on letter, individual messages indicating desire to utilize features is way more compelling.

Then I submit my essay from 2 years ago (https://blog.casa.io/why-bitcoin-needs-covenants/) and will quote myself:

"There are clearly a LOT of use cases that could potentially be unlocked with the right kind of covenant implementation. Personally, having spent 8 years working on high security multi-signature wallets, I'm most interested in vaults. I believe the value they offer is quite straightforward and is applicable to every single self-custody bitcoin user, regardless of what type of wallet they are running."

- Jameson

--
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/f8b37a59-0897-40df-a08e-7812c806a716%40mattcorallo.com.

[Antoine Riard]

Hi James,

Thanks for the additional thoughts.

> In your example script, you're not making use of the template hash or OP_NOP4.

I think this is where we're talking past each other as in example of the
script previosuly given, there is a CTV opcode used in the first OP_IF
branch.

Here again the script:

        OP_IF
                <my_little_vault_hash> OP_CHECKTEMPLATEVERIFY
        OP_ELSE
                <alice_bob_their_family_aggregated_pubkey> OP_CHECKSIG
        OP_ENDIF

Correct if I'm wrong, but in my understanding of BIP119, if the first
path is taken, the templating will be checked on the spending transaction
from the <my_little_vault_hash> stack element.

Of course, this is not a concern specific to OP_CTV and it's concerning
all the non bitcoin witness v1 traffic. Though, apart of the additional
work to change BIP119 and its code, I don't see why it's not technically
rational to make BIP119 a bitcoin witness v1 only.

Reducing the attack surface now, it's always less attack surface for
funds locked in the future thanks to CTV. Indeed, if you see technical
rational not to do CTV a segwit v1 and keep it as a legacy or you would
like I explain better such "blocksig overflow attack", I'm all hear.

The letter was asking for technical review. So here some "troubleshoot"
review of CTV, which I believe it's worthy to fix in its design. I don't
think it's a lot of work to make CTV a segwit v1, though I can suggest
pseudo-code if you wish so.

Re-iterating my previous commitment to advance on the review of CTV+ CSFS
(and BIP54) during the next 6 months. Your letter was asking for some kind
of goodwill signaling, here mine.

Thanks for the degree of professionalism you're upholding in the wish
to move the lines forward.

Best,
Antoine
OTS hash: 03eedd0ff78d4417c53cb0eb5660c89d5d13f6e1c4fc55a8d7f2bb83f209ce5b

[Anthony Towns]

On Tue, Jun 10, 2025 at 06:19:59AM -0700, Greg Sanders wrote:
> 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.

I think the easy way to do this is to expect both an implementation of the
features in question, and an interesting MVP/demo of how those features
can be used in practice. You then draw the line between a collection of
features that's implemented and has useful demos, versus ones that aren't
implemented or don't yet have interesting demos. If features are ready
roughly simultaneously but are largely unrelated (ie, all the interesting
demos use one set or the other but not both), then do them in parallel.

From my perspective, the main reasons that approach has not been helpful
with CTV is because:

(a) CTV advocacy has come packaged with a "recursive covenants are
evil, we must design to prevent them" argument, which has served
as opposition to just about every approach other than CTV (eg,
resulting in people doing design work on PAIRCOMMIT versus just
using CAT)

(b) there has been huge resistance to the idea of implementing demos
of useful things on top of proposed features when that's brought up
as something people might expect to see prior to feature activation

Maybe (hopefully!) that's changing with the recent PR to bip 119 [0]
and the efforts at actually building Ark with CTV; if so, I think it's an
easy and fairly objective way of figuring out when to release a feature
set versus continuing to expand it.

[0] https://github.com/bitcoin/bips/pull/1792

As I've said elsewhere, I believe the combination of "TXHASH",CSFS,CAT
would be fairly pleasant for an eltoo/ln-symmetry design/implementation
(where "TXHASH" could just mean "PUSH_TEMPLATE_HASH", rather than
necessarily being programmable tx introspection).

I believe it would be possible to build interesting prototypes for:

- eltoo/ln-symmetry/penalty-free-channels
- daric/fixed-penalty-channels
- ark
- ptlcs (via CSFS)
- john laws' channel factories
- lightning over ark?
- more blockspace-efficient bitvm intepreters? (via CAT?)

If there were an open letter signed by 50 developers (or funders)
committing to prototyping half a dozen different projects using proposed
new features, and giving an understandable reports on how well (or not)
the features end up working, that would be a lot more inspiring than the
current approach that's hard to interpret as anything other than "hey,
here's a bunch of people who will harass you on twitter and insult you
on podcasts until they get what they want".

(Personally, while I think vaults are interesting, I don't think
there are interesting vault behaviours that you can implement with the
collection of opcodes that are currently being advocated for activation;
jamesob's simple-ctv-vault and the cat-based purrfect_vault included,
so I'm not listing that here. Personally, I find it hard to understand
what the purrfect_vault stuff is actually doing, hence the part about
also having an "understandable report"...)

Cheers,
aj

[Anthony Towns]

On Tue, Jun 10, 2025 at 01:23:06PM +0000, Andrew Poelstra wrote:
> > 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.

Here's one way to get a list of such places:

$ git log src/script/ | grep ^Author: | head -n10000 | sort | uniq -c | sort -rn | head -n20

I feel pretty sure you've got my telegram contact info too, if nothing
else.

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

I think if you're looking at it as "targeting" people, that's probably
not going to be very constructive. It certainly comes across as an
implied threat.

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

I've written my perspective of what core's role in this should be
[0], and am happy to discuss that further if there's some way in which
that approach falls apart. The approach proposed there doesn't require
pressuring core for support.

[0] https://delvingbitcoin.org/t/bitcoin-forking-guide/1451

From my perspective, the CTV discussion has missed important steps,
and instead of those steps being taken, advocates have been attempting
to use public pressure to force adoption on an "accelerated timeline"
pretty much continuously for at least three years now. I've tried to help
CTV advocates take the steps I believe they've missed, but it's mostly
resulted in silence or insults rather than anything constructive. At
least from where I sit, this is just creating incentive problems, not
solving them.

> 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

Asking for "integration" as well as review presupposes the outcome of the
review, which doesn't come across as very respectful of the reviewers'
opinions, for what it's worth.

To analogise to book publishing, there are two sorts of review one might
undertake: if you're an editor or beta reader, when you review a book,
you can engage with the author and suggest ways in which the book seems
flawed and can be improved; on the other hand, if you're a columnist,
the book is already published, and the only thing you can do is recommend
whether the book is worth buying and reading or not.

If you're asking for the first sort of review, for that to be a
success, you need an author or community that's willing to engage with
criticisms, rather than, for instance, dismissing them in advance as
bikeshedding. Matt's already raised some specific issues in this thread
that could be engaged with and resolved, for instance, as has Greg
Sanders. I don't think you've engaged with either, and while James has,
it's only been to dismiss them.

If you really want this to be treated as final unchangeable proposal
and just get a detailed "CTV+CSFS sucks, 0 stars, NACK" review that
will inevitably be used to justify another round of "core are idiots
who are killing bitcoin, we have to replace them now", I guess I can
provide that; but I don't see a way of doing that while maintaining my
(already pretty shaky) assumption that "this is a serious proposal by
serious people who are willing to engage with criticism and resolve
problems with their ideas, they're just ... a bit over-excited and have
other demands on their time right now I guess".

Cheers,
aj

[Matt Corallo]

Thanks Jameson.

I think this is a much more valuable contribution to encouraging developers to work on covenants
than some other parts of this thread.

Is there a specific protocol utilizing covenants that you wish to implement at Casa (I assume Vaults
maybe, but can you sketch the high-level setup and considerations)?

Thanks,
Matt

On 6/13/25 7:08 AM, Jameson Lopp wrote:
> > Unlike a generic "We Want Things" sign-on letter, individual messages indicating desire to
> utilize features is way more compelling.
>

> Then I submit my essay from 2 years ago (https://blog.casa.io/why-bitcoin-needs-covenants/ <https://
> blog.casa.io/why-bitcoin-needs-covenants/>) and will quote myself:

>
> "There are clearly a LOT of use cases that could potentially be unlocked with the right kind of
> covenant implementation. Personally, having spent 8 years working on high security multi-signature
> wallets, I'm most interested in vaults. I believe the value they offer is quite straightforward and
> is applicable to every single self-custody bitcoin user, regardless of what type of wallet they are
> running."
>
> - Jameson
>

> bitcoindev+...@googlegroups.com <mailto:bitcoindev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f8b37a59-0897-40df-

> a08e-7812c806a716%40mattcorallo.com <https://groups.google.com/d/msgid/bitcoindev/
> f8b37a59-0897-40df-a08e-7812c806a716%40mattcorallo.com>.
>

[Antoine Poinsot]

Jameson,

Thanks for sharing. Although i grew more skeptical of the reactive security model of vaults as i implemented them in practice for real users, i can appreciate people's mileage may vary.

That said, consensus-enforced vaults require a mechanism to forward any amount received on a script A to a pre-committed script B. CTV+CSFS does not enable this, and a primitive that actually does (like CCV) is more controversial because of its potency. I see the CTV+CSFS bundle as maximizing "bang for your buck" in terms of capabilities enabled compared to the accompanying risk. If we do want vaults, then we need to get past the MEVil concerns and much more interesting primitives are actually on the table.

I also appreciate that CTV is nice to have for CCV vaults, but a potential future use case that is not enabled by one proposal cannot be used to motivate said proposal.

Best,
Antoine Poinsot

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_fxwKLdst9tYQqabUsJgu47xhCbwpmyq97ZB-SLWQC9Xw%40mail.gmail.com.

[Harsha Goli]

​I think the easy way to do this is to expect both an implementation of the features in question, and an interesting MVP/demo of how those features can be used in practice. You then draw the line between a collection of features that's implemented and has useful demos, versus ones that aren't implemented or don't yet have interesting demos.

​....

​....

​(b) there has been huge resistance to the idea of implementing demos of useful things on top of proposed features when that's brought up as something people might expect to see prior to feature activation

After discussing this further with Matt Corallo in another thread, I find myself agreeing with this perspective. It makes sense to require both actual implementation and convincing demonstrations as a way to move forward. However, creating these demonstrations is not an easy task. Although there are already written explanations for CTV + CSFS, the response to those efforts has left many supporters of these changes feeling unsure. They’re not confident that putting in more time and resources will lead to real progress.

The situation seems to split into two distinct groups. First, there are the smaller Bitcoin-focused teams (many of whom we know personally) that are resource constrained. These teams could leverage covenants in innovative ways, but they’re operating on tight budgets. For them, participating in this process can’t be a leap of faith; they need more assurance that their efforts won’t be in vain, especially given how long CTV (now with CSFS) has been in discussion (6 years!). As Tiero from ArkLabs put it: "@ArkLabsHQ might not even exist by the time a soft fork is implemented."

On the other hand, there are the large-scale custodians with significant resources at their disposal. These organizations could theoretically drive adoption, but even for them, the uncertainty around activation makes it a risky bet. Instead, they’ve opted for more predictable solutions, like establishing Trust companies, which provide legal guarantees and protections such as bankruptcy remoteness. While this approach is costly and time-intensive, it’s seen as a safer and more reliable path. We've already watched major players like NYDIG, BitGo, and ZeroHash go this route.

As a result, we’re in a tough spot. Those with the resources to contribute are prioritizing legal frameworks over engineering solutions, while smaller teams that could truly benefit from CTV are holding back to avoid jeopardizing their survival.

​From my perspective, the CTV discussion has missed important steps, and instead of those steps being taken, advocates have been attempting to use public pressure to force adoption on an "accelerated timeline" pretty much continuously for at least three years now. I've tried to help CTV advocates take the steps I believe they've missed, but it's mostly resulted in silence or insults rather than anything constructive.

I went through the Bitcoin forking guide in detail and found it both impressive and incredibly useful. I’ve even put together a checklist inspired by it, which I’m actively using to ensure I’m covering every step thoroughly. This ties into the industry survey I mentioned earlier (something I’m genuinely excited about).

I’ve tried reaching out a few times via delving and Twitter DMs to get your feedback but haven’t heard back yet (I don't have your telegram or signal!). Since you seem open to sharing input here, I’d love to hear your thoughts on my approach. Your perspective would mean a lot!

​Matt's already raised some specific issues in this thread that could be engaged with and resolved

I broke out in a private email thread to address his concerns. I'm bringing the core of our issues back to the main thread here (at the top of this email).

Thank you,

Harsha, sometimes known as arshbot

--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/KJF6A55DPJ8/unsubscribe. To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aEvC_zT3TEsjxc9o%40erisian.com.au.

[Jameson Lopp]

Casa (and many other companies focused on custody products) would love to see vaulting functionality. I don't think any of us are too hung up on the details of the particular implementation - we would rather have a "good" tool than not have any tool because consensus has not been achieved for a "perfect" solution.

What is the problem that makes vaults desirable? It's frankly because there's no such thing as perfect security. Even if one designs an architecture that is nearly perfectly secure against external threats, the issue of internal threats (such as oneself, via social engineering) will remain. The ability to require high value funds to sit in a "quarantine / cooldown" address for some period of time before they can be sent to an arbitrary address enables additional security measures a la watchtowers to be designed. Being your own bank is still an incredibly scary proposition because it's quite difficult to design custody solutions that tolerate failures without leading to catastrophic loss. The more tools that custody application engineers have available to them, the more guardrails we can build into wallet software, and thus hopefully the more comfortable we can make the general public with the idea of taking on the responsibility of self custody.

To be clear, I'm not aware of CSFS improving the vaulting functionality already available via CTV. As far as I can tell, CSFS is one of the least controversial opcodes proposed in a long time and just seems to be an all-around win with no risks / trade-offs, so why not bundle it in?

I'm not sure how to parse Antoine's claim that CTV+CSFS doesn't enable vaults given that there has already been a CTV vault client proof of concept for 3 years: https://github.com/jamesob/simple-ctv-vault

[Sjors Provoost]

Hi Jameson,

CTV does enable vaults, but the user has to (carefully) move coins into the vault themselves. Because CTV commits to the amount, among other things, you can't simply publish a vault address and receive arbitrary amounts there. They'd be stuck, committing to an impossible to satisfy CTV hash.

There's also the question of what, if anything, the user needs to backup after each deposit [0]. It's probably just the deposit transaction id, which is arguably something that can be recovered with some (?) work.

OP_CCV enables a more flexible design where the user can receive arbitrary amounts directly into their vault address, and with nothing to backup after initial setup (seeds + descriptor-like-thing).

Here's a demo functional test for an OP_CCV vault (without CTV): https://github.com/bitcoin/bitcoin/pull/32080

The problem with both demos is that they use boutique software. There's not yet a potentially interoperable standard to describe these things.

Hopefully some simple vault schemes can be shoehorned into the existing output descriptor paradigm [1], because inventing a whole new way of making vault-aware wallets interoperable would take many years.

To illustrate such schemes, I'd love to see a working demo using just a (patched) Bitcoin Core wallet. Though perhaps a library like BDK[2] is an easier platform for such ideation.

- Sjors

[0] https://github.com/jamesob/simple-ctv-vault/issues/9
[1] https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766/8
[2] https://github.com/bitcoindevkit

> Op 13 jun 2025, om 17:41 heeft Jameson Lopp <jameso...@gmail.com> het volgende geschreven:
>
[...]

>
> I'm not sure how to parse Antoine's claim that CTV+CSFS doesn't enable vaults given that there has already been a CTV vault client proof of concept for 3 years: https://github.com/jamesob/simple-ctv-vault
>
> On Fri, Jun 13, 2025 at 9:07 AM Antoine Poinsot <daro...@protonmail.com> wrote:

[...]

> That said, consensus-enforced vaults require a mechanism to forward any amount received on a script A to a pre-committed script B. CTV+CSFS does not enable this, and a primitive that actually does (like CCV) is more controversial because of its potency.

[...]

[gmaxwell]

I'm struggling to figure out what kind of useful 'vault' could be constructed from CTV that isn't equivalent to "presign a transaction that sweeps your funds to an emergency address".  Can someone clue me in?

It might be helpful to point to examples of where similar techniques are used in other blockchains that already facilitate their construction.  This isn't bitcoin-twitter,  it's permissible to observe some other system being used in useful ways...

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_faQhCGS78y0Nggm_h%3Dx_cEtshhbrZDDhQ%3DFEgbDXkc-Q%40mail.gmail.com.

[Jameson Lopp]

On Sat, Jun 14, 2025 at 11:58 AM Sjors Provoost <sj...@sprovoost.nl> wrote:

Hi Jameson,

CTV does enable vaults, but the user has to (carefully) move coins into the vault themselves. Because CTV commits to the amount, among other things, you can't simply publish a vault address and receive arbitrary amounts there. They'd be stuck, committing to an impossible to satisfy CTV hash.

Understood. OP_CCV enables more flexible / user friendly vaults. Sounds good to me!

I'll just reiterate my previous point that custody software services would rather have a "good" tool in the hand than a better solution waiting on the distant horizon.

[Jameson Lopp]

On Sat, Jun 14, 2025 at 12:06 PM gmaxwell <gmax...@gmail.com> wrote:

I'm struggling to figure out what kind of useful 'vault' could be constructed from CTV that isn't equivalent to "presign a transaction that sweeps your funds to an emergency address".  Can someone clue me in?

Sure. As I mentioned in my article years ago, one can technically implement covenant functionality today via presigned transactions and ephemeral key material. But there is a vast gap between what is technically possible and what is practical, which is why I believe you can't find any such software in existence. Using presigned transactions means you have to regularly update your vault scheme whenever your UTXOs change. This becomes incredibly problematic if we're talking about a multisignature setup with geographically distributed keys. And ephemeral keys relies upon user being able to securely delete key material, which comes with its own host of problems.

James went into further detail as to why presigned transaction based vaults are simply unworkable: https://delvingbitcoin.org/t/the-unsuitability-of-presigned-transactions-for-vaults/113

As I see it, a setup where you presign a transaction to sweep funds to an emergency address is only particularly useful for the situation in which key material becomes inaccessible. It doesn't really help you in the case where key material is compromised. Vaults specifically allow for a user to recover from a situation in which a signing threshold of keys have been compromised.

[Greg Maxwell]

On Sat, Jun 14, 2025 at 8:17 PM Jameson Lopp <jameso...@gmail.com> wrote:

Sure. As I mentioned in my article years ago, one can technically implement covenant functionality today via presigned transactions and ephemeral key material. But there is a vast gap between what is technically possible and what is practical, which is why I believe you can't find any such software in existence. Using presigned transactions means you have to regularly update your vault scheme whenever your UTXOs change. This becomes incredibly problematic if we're talking about a multisignature setup with geographically distributed keys. And ephemeral keys relies upon user being able to securely delete key material, which comes with its own host of problems.

What's the problem for securely deleting?  The operation is atomic-- e.g. software can be written that performs it as a single step and never even hands the users the private key.  If you need to attest to a third party the ephemeral key can have 1-N multisigners, which has none of the normal challenges for multisigning since they don't need to retain information or check anything (in fact, it could even be blinded).

From a durability perspective you also have the same issue of maintaining a script, if you're avoiding that by always constructing it programmatically and backing up the scheme, you can more or less do that with the presigned approach: just stick the ephemeral signature in a taproot annex in the transaction paying the coins to the 'vault' script and then immediately all the participants have the required data to deterministically construct the intermediate transaction.

The result is essentially identical properties to a 'vault' constructed with CTV and needs no consensus change.

As I see it, a setup where you presign a transaction to sweep funds to an emergency address is only particularly useful for the situation in which key material becomes inaccessible. It doesn't really help you in the case where key material is compromised. Vaults specifically allow for a user to recover from a situation in which a signing threshold of keys have been compromised.

But that is the only kind of vault you can construct from CTV isn't it?  One where the stationary output can go to one of multiple preconstructed outputs, typically one 'immediately' and the other after a delay that starts when a particular transaction is released.  AFAICT, the CTV approach does not allow you to stage an output address and then either abort or allow it to continue.

(though I remain dubious as to the utility of that improvement, since if you can secure the rescue/abort key you could use the process for the primary. ... and because of the lack of implementation of these tools in systems where its already easy to do so...)

 

[Sanket Kanjalkar]

Do you mean arbitrary output address that is unknown at commitment time? Otherwise, I think the current CTV vault does allow abort/allowing from "stage area" to "hot area" or abort to "rescue area". While general purpose recursive vaults will allow funds back into same "cold area", I think it is possible to also move funds back into same back under the same cold keys with a bounded recursion CTV provides.

(though I remain dubious as to the utility of that improvement, since if you can secure the rescue/abort key you could use the process for the primary.)

Primary key is used often for regular withdrawals from the vault. The rescue/abort key will only be used in case there is something wrong. If there is something that you don't intent you use at all, you can go 10 extra steps to secure it. Maybe store in secure guarded physical locations, or require offchain security authorization protocols to secure them. You might not do these for regular primary keys if you intend to use them often.

 And even if you secure rescue key as the primary key, there is still value because the attacker has to get both of them. We can see that in practice, people use multisig instead of single-sig even though both keys are probably secured to the same degree of security.   


Finally, on the usefulness of vaults; based on my own observation of all the hacks (bitcoin and wider crypto), in most cases it is not the key that is stolen but rather the authorization process or UI/UX hacks or something else up the signing stack is compromised. Having reactive security to "undo" feels valuable in this scenario. 

 

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

--

Sanket1729

[Greg Maxwell]

On Sat, Jun 14, 2025 at 11:50 PM Sanket Kanjalkar <sanke...@gmail.com> wrote:

Do you mean arbitrary output address that is unknown at commitment time? Otherwise, I think the current CTV vault does allow abort/allowing from "stage area" to "hot area" or abort to "rescue area". While general purpose recursive vaults will allow funds back into same "cold area", I think it is possible to also move funds back into same back under the same cold keys with a bounded recursion CTV provides.

Moving funds back to the initial key that the attacker already has demonstrated the ability to release from doesn't seem useful to me.  -- though that is a thing the presigned example I gave doesn't do.

Finally, on the usefulness of vaults; based on my own observation of all the hacks (bitcoin and wider crypto), in most cases it is not the key that is stolen but rather the authorization process or UI/UX hacks or something else up the signing stack is compromised. Having reactive security to "undo" feels valuable in this scenario. 

Is there an example of a hack that has been defeated by one?  It would be interesting to see the exact workflow.

If the scheme is just released into a 'hot area' and the hot area keys have the power to send the coins anywhere, presumably the attacker will attack the hot area keys and wait for funds to be moved there and instantly sweep once they're there.  If the hot area keys are presumed secure, then they can be multisig on the release from 'cold'.

[Sanket Kanjalkar]

On Sat, Jun 14, 2025 at 5:01 PM Greg Maxwell <gmax...@gmail.com> wrote:

On Sat, Jun 14, 2025 at 11:50 PM Sanket Kanjalkar <sanke...@gmail.com> wrote:

Do you mean arbitrary output address that is unknown at commitment time? Otherwise, I think the current CTV vault does allow abort/allowing from "stage area" to "hot area" or abort to "rescue area". While general purpose recursive vaults will allow funds back into same "cold area", I think it is possible to also move funds back into same back under the same cold keys with a bounded recursion CTV provides.

Moving funds back to the initial key that the attacker already has demonstrated the ability to release from doesn't seem useful to me.  -- though that is a thing the presigned example I gave doesn't do.

Finally, on the usefulness of vaults; based on my own observation of all the hacks (bitcoin and wider crypto), in most cases it is not the key that is stolen but rather the authorization process or UI/UX hacks or something else up the signing stack is compromised. Having reactive security to "undo" feels valuable in this scenario. 

Is there an example of a hack that has been defeated by one?  It would be interesting to see the exact workflow.

I presume in this case any rational attacker will not attempt something like this until they know they can succeed. A weaker argument here might be that this setup by itself would discourage attackers to attempt to continue :). I can try to look up examples for defeated hacks, but they might be hard to find.

If the scheme is just released into a 'hot area' and the hot area keys have the power to send the coins anywhere, presumably the attacker will attack the hot area keys and wait for funds to be moved there and instantly sweep once they're there.  If the hot area keys are presumed secure, then they can be multisig on the release from 'cold'.

Any amount of money that you move in hot wallet can be stolen. The point here would be limit the theft exposure, for example, you never have more than X BTC in hot wallets. I agree that this might be awkward to do in practice with CTV vaults because you have to move the entire UTXO into "hot area" in order to send change back. Having a powerful vault primitive helps avoid this issue with change amounts. But in case of CTV, this can be somewhat mitigated with careful UTXO management.

When moving larger amounts across wallets, you would move them in increments of X BTC one by one limiting exposure. 

--

Sanket Kanjalkar

[Jameson Lopp]

On Sat, Jun 14, 2025 at 5:31 PM Greg Maxwell <gmax...@gmail.com> wrote:

On Sat, Jun 14, 2025 at 8:17 PM Jameson Lopp <jameso...@gmail.com> wrote:

Sure. As I mentioned in my article years ago, one can technically implement covenant functionality today via presigned transactions and ephemeral key material. But there is a vast gap between what is technically possible and what is practical, which is why I believe you can't find any such software in existence. Using presigned transactions means you have to regularly update your vault scheme whenever your UTXOs change. This becomes incredibly problematic if we're talking about a multisignature setup with geographically distributed keys. And ephemeral keys relies upon user being able to securely delete key material, which comes with its own host of problems.

What's the problem for securely deleting?  The operation is atomic-- e.g. software can be written that performs it as a single step and never even hands the users the private key.  If you need to attest to a third party the ephemeral key can have 1-N multisigners, which has none of the normal challenges for multisigning since they don't need to retain information or check anything (in fact, it could even be blinded).

It's the same problem as securely generating and storing keys. In order for presigned transaction vaults to actually be trustworthy then ephemeral key usage needs to occur on a hardened offline device that is highly unlikely to be compromised. I'm not aware of any of the hardware manufacturers offering functionality for generating and signing with ephemeral keys.

 

From a durability perspective you also have the same issue of maintaining a script, if you're avoiding that by always constructing it programmatically and backing up the scheme, you can more or less do that with the presigned approach: just stick the ephemeral signature in a taproot annex in the transaction paying the coins to the 'vault' script and then immediately all the participants have the required data to deterministically construct the intermediate transaction.

The result is essentially identical properties to a 'vault' constructed with CTV and needs no consensus change.

As I see it, a setup where you presign a transaction to sweep funds to an emergency address is only particularly useful for the situation in which key material becomes inaccessible. It doesn't really help you in the case where key material is compromised. Vaults specifically allow for a user to recover from a situation in which a signing threshold of keys have been compromised.

But that is the only kind of vault you can construct from CTV isn't it?  One where the stationary output can go to one of multiple preconstructed outputs, typically one 'immediately' and the other after a delay that starts when a particular transaction is released.  AFAICT, the CTV approach does not allow you to stage an output address and then either abort or allow it to continue.

I was referring to presigned transactions for which the original signing keys still exist, so we're probably talking past each other a bit. 

[Greg Maxwell]

On Sun, Jun 15, 2025 at 2:40 PM Jameson Lopp <jameso...@gmail.com> wrote:

It's the same problem as securely generating and storing keys. In order for presigned transaction vaults to actually be trustworthy then ephemeral key usage needs to occur on a hardened offline device that is highly unlikely to be compromised. I'm not aware of any of the hardware manufacturers offering functionality for generating and signing with ephemeral keys.

What device(s) generates the key/key(s) that can immediately terminate the vault release and take custody of the coins?

[Owen Kemeys]

On Sunday, 15 June 2025 at 10:10:59 UTC-6 Jameson Lopp wrote:

It's the same problem as securely generating and storing keys. In order for presigned transaction vaults to actually be trustworthy then ephemeral key usage needs to occur on a hardened offline device that is highly unlikely to be compromised. I'm not aware of any of the hardware manufacturers offering functionality for generating and signing with ephemeral keys.

I'm talking my employer's book, but you can approximate this function for sure on Foundation Passport by generating a child seed then loading it as a temporary signing key (forgotten on power off). I'm sure Coldcard offers something similar and perhaps others. Of course, you'd have to remember to delete the seed before putting the device away, and it's derived, not generated from scratch, so undermining some of the security. But it's close, and the desired functionality could be added if there was demand, all the pieces are there.

The upcoming Passport Prime device would be perfectly placed to serve a workflow in a secure environment that generates an ephemeral key, signs, discards, and passes the PSBTs back to the online device. This is niche enough that we're unlikely to write the applet ourselves, but that's why it's an open source platform - hopefully some vault project will come along and assemble the building blocks in the right way; it shouldn't be hard.

[Steven Roose]

Hey all

I've been following the discussion and noticed TXHASH is mentioned a lot. As a signer of the letter and author of the TXHASH proposal, I'd like to chime in with some thoughts.

However, I'd like to first express my disappointment with the amount of drama this letter has caused. It quite literally merely asks Core contributors to put this proposal on their agenda with some urgency. No threats, no hard words.
Given that only a handful of Core contributors had thus far participated in the conversation on the proposal elsewhere, it seemed like a suitable next step to communicate that we want Core contributors to provide their position within this conversation.
I strongly stand against an approach involving independent activation clients and I think the sentiment of this e-mail aligns with the preference of having Core be involved in any deployment of protocol upgrades.

On the proposal itself. I have heard some mentions of TXHASH and why we, as the developer community, wouldn't go  straight for TXHASH.

• I think TXHASH is too far from being ready at this point:
  
• The TXHASH BIP and spec has not had the level of review/engagement that I had hoped for. I'm personally pretty happy with the result, especially since it only has had serious looks from myself and Rearden. But it definitely needs a lot more scrutiny. It's a very opinionated design (I think it's unavoidable for such an opcode), so there is a lot of room for making different and maybe better decisions on many fronts.
• Once we have the TXHASH semantics, it would be very valuable to consider also introducing the same semantics as a top-level sighash flag system, so you can spend coins directly with a sighash based on TXHASH semantics. (I dubbed this TXSIGHASH and I recently did some simulations on how such a construction would look for fee sponsoring and stacking https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760)
• However, this also invites some additional review of possible taproot changes (pay-to-tapscript, re-adding parity byte, ..) and will necessarily take some more time for consideration and design.
  
• I strongly believe it would benefit development of new bitcoin use cases if we would have a simple version of templating and rebindable signatures sooner rather than later. Both BitVM and Ark are fairly recent ideas that stand to benefit significantly from such new functionality, but I think having them actually available will invite a lot more engagement leading to new ideas and new improvements. These are not use case-specific changes, but useful general building blocks.
  
• Both CSFS and CTV are fairly unopinionated opcodes by design, when you think of CTV in the sense that it fixes the minimum tx fields to ensure txid stability.
  
• I think there is both enough excitement for this proposal and there would be enough future excitement for a TXHASH or CCV addition that I don't fear upgrade churn will be a future hurdle.
• Even after possible TXHASH activation, I think there will stay some demand for the simpler CTV/TEMPLATEHASH variant. It doesn't just save a byte on the wire, but thinking in a txid-stable model is just more intuitive. I believe that many advanced use cases will take advantage from doing things the TXHASH way (enabling stacking and cheaper fee sponsoring), but some developers will always favor the simplicity of txid stability over the benefits of adding complexity.
  

The above arguments convinced me that an activation based on CTV and CSFS makes sense today. We have lots of developers waiting to make use of the functionality it enables and we can continue development of further changes meanwhile.

That being said, I'm in no way married to the exact details of the proposals.

• I am sympathetic to worries of changing legacy/v0 script. I failed to convince myself of any valuable usage for bare CTV.
• I am sympathetic to the consideration of revisiting scriptSig and annex-related modifications to the template hash.
  
• I am sympathetic to the decision to optimize better for the rebindable signature use cases, meaning:
  
• the idea to swap CTV for a TEMPLATEHASH opcode which adds a 1-byte VERIFY for the template use case but saves 33 bytes for the signature use case
• the addition of an INTERNALKEY opcode, saving an additional 33 bytes for the rebindable signature use case

All of the above changes I think can be decided on with minimal bikeshedding and still encompass the same semantics of the original proposal.

Best

Steven

On 6/9/25 12:40, 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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com.

[Antoine Poinsot]

Steven,

I'd like to first express my disappointment with the amount of drama this letter has caused.

Likewise. As i mentioned earlier i think this bundle of capabilities is worth considering for a use case driven soft fork. I felt like, despite the lack of substantive work on the proposal, we were finally going somewhere in the discussion on extending Bitcoin's scripting capabilities.

Instead of addressing minor objections to the design of the operations and working on demonstrating (real) use cases, the champion chose the route of political pressure on the Bitcoin Core project. Signatories backed this approach.

In changing Bitcoin, the process matters as much as the outcome. If Bitcoin can be changed through a shouting match and on the basis of misleading pseudo use cases, it would be a major fuck up. Likewise if a suboptimal change can be rammed through without addressing objections and reasonable requests from the technical community, by bamboozling industry stakeholders into the false dichotomy "it's either this or ossification".

Bitcoin Core cannot, in my opinion, facilitate setting such a precedent. Therefore this effort sets us back a long way in getting a consensus change merged there, and on the broader path of extending Bitcoin's scripting functionalities

It quite literally merely asks Core contributors to put this proposal on their agenda with some urgency.

This is incorrect and misrepresenting the content of the letter. It specifically asks, i'm quoting "integration of CTV (PR #31989 or similar)". This is asking Core to merge a pull request implementing a contentious consensus change. And so, not by making the case for it with strong technical arguments but by presenting signatures from industry stakeholders. I trust we all both agree it is inadvisable to change the Bitcoin Core decision process from making software changes based on objective rough technical consensus toward making software changes based on the subjective intentions of whoever has influence in the space at the moment.

Given that only a handful of Core contributors had thus far participated in the conversation on the proposal elsewhere

And pressure to merge code for an obviously controversial consensus change is a great way to make sure not more of them engage, if lurking at how previous CTV discussions went wasn't enough.

it seemed like a suitable next step to communicate that we want Core contributors to provide their position within this conversation

How could you ever think it be a "suitable next step"? Bitcoin Core contributors spend their days maintaining the existing Bitcoin network, where making it boringly stable is success. Asking the project to merge a contentious consensus change, disregarding conceptual review, is just laughable. I don't see how piling a sign-on letter on top of this would improve anything.

In conclusion, i would like to state i understand the frustration of this proposal not making progress and how it led many signatories to get on board with the letter. I do not ascribe bad intentions to most of them. However the effect of this letter has been, as could have been expected, a major setback in making progress on this proposal (or more broadly this bundle of capabilities). I am not sure how we bounce back from this, but it necessarily involves someone standing up and actually doing the work of addressing technical feedback from the community and demonstrating (real) use cases. The way forward must be by building consensus on the basis of strong objective, technical, arguments. Not with a bunch of people stating interest and nobody acting up and helping the proposal move forward.

Best,
Antoine Poinsot

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io.

[/dev /fd0]

I created a wiki page for [use cases][0] in December 2024. It does not include LN SYMMETRY and other things possible when CHECKSIGFROMSTACK is used in combination with CHECKTEMPLATEVERIFY.

I don't think there's anything wrong with the language used in the letter or the intentions of those who signed it. The misinterpretation may be genuine or simply an excuse to stall the process for a few more years. That said, I had suggested [rephrasing][1] one of the paragraphs to help avoid misunderstanding and keep the focus on technical discussion.

I really appreciate James O'Beirne for his efforts, as well as the others who signed this letter. Most users prefer public communication about soft forks.

[0]: https://en.bitcoin.it/wiki/Covenants_Uses
[1]: https://github.com/ctv-csfs/ctv-csfs.github.io/issues/15

/dev/fd0
floppy disk guy

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4%3D%40protonmail.com.

[Harsha Goli]

​If Bitcoin can be changed through a shouting match and on the basis of misleading pseudo use cases, it would be a major fuck up.

ACK

​Bitcoin Core cannot, in my opinion, facilitate setting such a precedent.

ACK

​I trust we all both agree it is inadvisable to change the Bitcoin Core decision process from making software changes based on objective rough technical consensus toward making software changes based on the subjective intentions of whoever has influence in the space at the moment.

ACK

How could you ever think it be a "suitable next step"? Bitcoin Core contributors spend their days maintaining the existing Bitcoin network, where making it boringly stable is success.

Many signatories were surprising to see. After speaking with them, they signed not because they lack respect for core developer's priorities, or take Bitcoin's boring stability for granted (I promise you I do not).

Most people signed because they really had no idea what the next step ought to be, and the pressure for transaction commitments was so much so that a bad option (piling of a sign-on letter) was more optimal than inaction.

In conversations prior to the letter going out (facilitated by my industry survey), I only recieved admonishment of the letter from many of the signatories. I actually don't know of a single person who considered it as an explicitly good idea. And still they signed. There's signal in that.

​In conclusion, i would like to state i understand the frustration of this proposal not making progress and how it led many signatories to get on board with the letter.

I (and many signatories) also understand the frustration the letter had for many folks. We did not intend to disrespect the important work performed by anyone, nor did we intend to disrupt any roadmaps by a railroading of "our agenda".

Having had the weekend to speak to many ctv+csfs proponents, I've made sure to communicate this point of view to them. I've also made sure that there is absolutely zero substance backing any "threat" but I now understand earlier versions included considerations for an activation client (which wasn't intended as a threat but I now understand how that could've come across).

For better or for worse, the letter happened. It carried many signals, and it helped me understand how many people really needed this (that hadn't been clear before). I'm going to try to make the best out of it, and utilize the ctv+csfs feedback that's come come out of it.

With respect,

Harsha, sometimes known as arshbot

On Tue, Jun 17, 2025 at 10:34 AM, Antoine Poinsot <daro...@protonmail.com> wrote:

Steven,

I'd like to first express my disappointment with the amount of drama this letter has caused.

Likewise. As i mentioned earlier i think this bundle of capabilities is worth considering for a use case driven soft fork. I felt like, despite the lack of substantive work on the proposal, we were finally going somewhere in the discussion on extending Bitcoin's scripting capabilities.

Instead of addressing minor objections to the design of the operations and working on demonstrating (real) use cases, the champion chose the route of political pressure on the Bitcoin Core project. Signatories backed this approach.

In changing Bitcoin, the process matters as much as the outcome. If Bitcoin can be changed through a shouting match and on the basis of misleading pseudo use cases, it would be a major fuck up. Likewise if a suboptimal change can be rammed through without addressing objections and reasonable requests from the technical community, by bamboozling industry stakeholders into the false dichotomy "it's either this or ossification".

Bitcoin Core cannot, in my opinion, facilitate setting such a precedent. Therefore this effort sets us back a long way in getting a consensus change merged there, and on the broader path of extending Bitcoin's scripting functionalities

It quite literally merely asks Core contributors to put this proposal on their agenda with some urgency.

This is incorrect and misrepresenting the content of the letter. It specifically asks, i'm quoting "integration of CTV (PR #31989 or similar)". This is asking Core to merge a pull request implementing a contentious consensus change. And so, not by making the case for it with strong technical arguments but by presenting signatures from industry stakeholders. I trust we all both agree it is inadvisable to change the Bitcoin Core decision process from making software changes based on objective rough technical consensus toward making software changes based on the subjective intentions of whoever has influence in the space at the moment.

Given that only a handful of Core contributors had thus far participated in the conversation on the proposal elsewhere

And pressure to merge code for an obviously controversial consensus change is a great way to make sure not more of them engage, if lurking at how previous CTV discussions went wasn't enough.

it seemed like a suitable next step to communicate that we want Core contributors to provide their position within this conversation

How could you ever think it be a "suitable next step"? Bitcoin Core contributors spend their days maintaining the existing Bitcoin network, where making it boringly stable is success. Asking the project to merge a contentious consensus change, disregarding conceptual review, is just laughable. I don't see how piling a sign-on letter on top of this would improve anything.

In conclusion, i would like to state i understand the frustration of this proposal not making progress and how it led many signatories to get on board with the letter. I do not ascribe bad intentions to most of them. However the effect of this letter has been, as could have been expected, a major setback in making progress on this proposal (or more broadly this bundle of capabilities). I am not sure how we bounce back from this, but it necessarily involves someone standing up and actually doing the work of addressing technical feedback from the community and demonstrating (real) use cases. The way forward must be by building consensus on the basis of strong objective, technical, arguments. Not with a bunch of people stating interest and nobody acting up and helping the proposal move forward.

Best,
Antoine Poinsot

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/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io.

--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/KJF6A55DPJ8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4%3D%40protonmail.com.

[Peter Todd]

On Wed, Jun 11, 2025 at 11:33:35AM -0400, Greg Sanders wrote:
> It clearly can be a liability if the relative utility of CTV is damaged by
> a possible future change, even non-consensus ones, some of which are
> already being deployed with non-zero miner support such as
> https://x.com/PortlandHODL/status/1921350395424563572 . This could have led
> to legitimate usage of CTV being trivially DoS'able. Good news is there are
> practical if not beautiful mitigations to this that don't involve annex
> commitment. See https://github.com/bitcoin/bitcoin/pull/32453 and
> https://github.com/petertodd/bitcoin/pull/10 for some relevant details.

Note that in this example the "mitigation" is simply enforcing what is optimal
for miners: mining annexes only when the annexes are required for the
transaction to be valid.

A miner who had allowed standard annexes who was *not* mining CTV transactions
because of a large uncommitted annex is just unnecessarily losing money. They
could easily take that exact transaction, remove the uncommitted annex, and
earn a bit more money. In much the same way that a miner can always do
themselves unnecessary harm by disabling the clean-stack check, and then
failing to mine perfectly valid transactions that would be more profitable if
the extraneous stack elements were removed (modulo non-segwit cases with
high-fee child transactions of course).

It may be a good idea for CTV to commit to annexes. But this issue isn't a
reason to do so.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[fiatjaf]

Good morning, I'm nobody and I certainly haven't ever contributed to Bitcoin Core, but I still wanted to say, just because no one mentioned these things, that CTV+CSFS would be great to enable the Spacechains and Statechains constructs.

On the spacechain front I've worked on two proof-of-concepts in the past, https://github.com/fiatjaf/simple-ctv-spacechain and https://github.com/nbd-wtf-soma and I know of at least two companies that showed interest in deploying decentralized spacechains, one was ZEBEDEE who wanted to sponsor a decentralized and open blockchain for asset transfers at the time I worked there, the other was Tether who was interested in an open blockchain dedicated to USDT. Of course these companies never made any real moves (besides ZEBEDEE sponsoring me for working on Soma after the fact) towards implementing any of these things because it was known at the time that the soft-forks required at the time (around 2020~2023) were all perceived to be "many years away".

Today I learned that Tether has deployed some kind of shit-chain called "usdt0" that isn't the same thing as a spacechain but has some overlap and likely wouldn’t exist today if a USDT spacechain had been available. There is also a very clear argument that if we had some kind of spacechain-for-assets deployed some years ago the entire utxoset-spam that came from the BRC-20 protocol would have not happened -- and arguably we could have perhaps saved at least some of the development efforts that went into the less bad alternative asset transfer protocols like Runes, RGB, Tap-ass and whatnot.

On the statechain front I have followed the development of Mercury wallet v1 (at some point I launched the "statecoin torch" -- to not say I didn't do anything) and later of the Mercury Layer blind-signing-server+client-side-statechain construct, and I still think it would have been a great protocol for transfer of Bitcoin value in many circumstances, but the fact that these statechains had a fixed lifespan given by nLockTime (a limitation required by the lack of APO or CTV+CSFS) certainly made it much less interesting.

I'm not claiming that if we'd had a covenant-enabling soft-fork available some years ago we would have spacechains thriving today and adding to the security budget and awareness of Bitcoin without causing any harm or using excessive blockspace and that blind statechains would be widely adopted for payments or inter-institution settlements, I am just telling some small anecdotes of some possibilities that we may have lost.

I'm also not saying that this soft-fork, if merged today, will cause people to work on these things, because probably these ships have already sailed, I'm merely highlighting that not doing anything has costs in lost opportunities and invisible risks, and that we don't know what ships haven't sailed yet or what we're losing today by postponing things again.

[Saint Wenhao]

> That is why it is better -- I can activate my own thing, without bothering you all.

After reading BIP-300 in its current form, I think it is too complex. Instead, much simpler constructions are already available, without any soft-forks. What is more: they were possible since 2009, and they can be implemented by raw Script, if needed, which makes them portable between many altcoins, which copy-pasted Bitcoin's source code, and also between different address types (excluding TapScript, because OP_SIZE will work only with DER signatures).

Example testnet transaction: https://mempool.space/testnet4/tx/cc159432ffb7a166abeccc79800e9616a09ea9ac6937080c2ca37b38671970e5
Example address: https://mempool.space/testnet4/address/tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d
Example Script: OP_SIZE 60 OP_LESSTHAN OP_VERIFY 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG

Here, each coin sender can decide, which difficulty should be picked for a given transaction output. When the size is required to be less than 60, then that coin can be moved after grinding around 256 hashes (one byte). Then, by lowering that value, it can be made 256 times harder, each time this value is decremented (down to 10, because 9-byte signature is the smallest valid one).

So, to sum up, the ability to lock output Scripts with Proof of Work is possible here and now, without any consensus changes. The only need for further changes is related to Merged Mining, because the way of transaction hashing is obviously different, than the way of hashing existing block headers. However, that model given above should be sufficient, to deploy some real, decentralized sidechains, on top of some existing chains, and see, how they would be used in practice.

czw., 12 cze 2025 o 02:02 Paul Sztorc <trut...@gmail.com> napisał(a):

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

I have done no such thing.

The bip300301_enforcer is in rust [0]. Furthermore, it is not an "alternative" to Core --  it must connect to Bitcoin Core, via ZMQ. (But it is an "activation client" -- of a kind.)

(Anyone who glanced at the github for 2 seconds, would see all of these things, by the way.)
(Sjors, you may be confusing my project, with Bitcoin Core, which contains python, including a siget-mining-script.)

CUSF is clever -- because it **frees** Core from the headache and responsibility of soft fork activation (which I know many people here hardly enjoy). That is why it is better -- I can activate my own thing, without bothering you all. And I don't have to "compete" with CTV to be further ahead "in line" (or whatever). So I am free to appraise CTV rationally.

We all know that Core is a meritocracy. And that every decision and sentence uttered by Core is a perfect work of divine truth -- free of all the flaws that have plagued every other organization throughout history. Lucky us! Just think, in other organizations, people sometimes allow their prejudice to color their judgement, occasionally jumping to conclusions that are incorrect -- not here though. Here it's all based on merit, baby. No need for a plan B!

Cheers,
Paul

[0] https://github.com/LayerTwo-Labs/bip300301_enforcer

--
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/f8220f1b-831a-4459-8dee-7fc81f4b666cn%40googlegroups.com.