From: Steven Roose <steven@roose•io>
To: James O'Beirne <james.obeirne@gmail•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Date: Tue, 17 Jun 2025 12:22:10 +0100 [thread overview]
Message-ID: <035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io> (raw)
In-Reply-To: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 9770 bytes --]
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:
o 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.
o 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)
o 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:
o 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
o 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+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io.
[-- Attachment #2: Type: text/html, Size: 12568 bytes --]
next prev parent reply other threads:[~2025-06-17 11:31 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 11:40 James O'Beirne
2025-06-09 12:51 ` Michael Folkson
2025-06-09 14:41 ` James O'Beirne
2025-06-09 15:56 ` Michael Folkson
2025-06-09 13:51 ` Matt Corallo
2025-06-09 14:43 ` James O'Beirne
2025-06-09 17:51 ` Matt Corallo
2025-06-09 19:27 ` /dev /fd0
2025-06-09 21:12 ` Matt Corallo
2025-06-09 18:55 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 2:02 ` Paul Sztorc
2025-06-09 23:02 ` Andrew Poelstra
2025-06-10 2:08 ` David A. Harding
2025-06-10 13:23 ` Andrew Poelstra
2025-06-10 17:17 ` Matt Corallo
2025-06-10 23:42 ` Antoine Riard
2025-06-12 3:34 ` James O'Beirne
2025-06-13 1:18 ` Antoine Riard
2025-06-10 23:42 ` Antoine Riard
2025-06-11 13:52 ` Peter Todd
2025-06-13 6:19 ` Anthony Towns
2025-06-13 14:50 ` Harsha Goli
2025-06-10 14:03 ` James O'Beirne
2025-06-10 16:56 ` Sjors Provoost
2025-06-10 17:15 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 19:04 ` Paul Sztorc
2025-06-11 18:09 ` Brandon Black
2025-06-10 2:28 ` Melvin Carvalho
2025-06-10 13:19 ` Greg Sanders
2025-06-11 14:12 ` James O'Beirne
[not found] ` <CAB3F3Dsf8=rbOyPf1yTQDzyQQX6FAoJWTg16VC8PVs4_uBkeTw@mail.gmail.com>
2025-06-11 16:50 ` James O'Beirne
2025-06-11 18:34 ` James O'Beirne
2025-06-11 20:30 ` Matt Corallo
2025-06-12 0:59 ` Harsha Goli
2025-06-12 18:04 ` Matt Corallo
2025-06-12 18:38 ` James O'Beirne
2025-06-12 18:43 ` Matt Corallo
2025-06-12 19:51 ` Andrew Poelstra
2025-06-12 22:44 ` Matt Corallo
2025-06-13 11:08 ` Jameson Lopp
2025-06-13 12:36 ` Matt Corallo
2025-06-13 13:07 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-13 15:41 ` Jameson Lopp
2025-06-14 15:58 ` Sjors Provoost
2025-06-14 20:05 ` Jameson Lopp
2025-06-14 16:06 ` gmaxwell
2025-06-14 20:17 ` Jameson Lopp
2025-06-14 21:31 ` Greg Maxwell
2025-06-14 23:50 ` Sanket Kanjalkar
2025-06-15 0:01 ` Greg Maxwell
2025-06-15 0:20 ` Sanket Kanjalkar
2025-06-15 14:40 ` Jameson Lopp
2025-06-15 17:43 ` Greg Maxwell
2025-06-15 19:43 ` Owen Kemeys
2025-06-13 5:50 ` Anthony Towns
2025-06-12 2:06 ` Greg Maxwell
2025-06-12 3:23 ` James O'Beirne
2025-06-17 11:22 ` Steven Roose [this message]
2025-06-17 14:34 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-17 16:40 ` Harsha Goli
2025-06-17 18:19 ` /dev /fd0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io \
--to=steven@roose$(echo .)io \
--cc=bitcoindev@googlegroups.com \
--cc=james.obeirne@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox