<div dir="ltr">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.<div><br></div><div>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.<br><br>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.</div><div><br></div><div>[0]: <a href="https://en.bitcoin.it/wiki/Covenants_Uses">https://en.bitcoin.it/wiki/Covenants_Uses</a><br>[1]: <a href="https://github.com/ctv-csfs/ctv-csfs.github.io/issues/15">https://github.com/ctv-csfs/ctv-csfs.github.io/issues/15</a><br><br>/dev/fd0<br>floppy disk guy</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jun 17, 2025 at 9:03 PM 'Antoine Poinsot' via Bitcoin Development Mailing List <<a href="mailto:bitcoindev@googlegroups.com">bitcoindev@googlegroups.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:Arial,sans-serif;font-size:14px">Steven,</div><div style="font-family:Arial,sans-serif;font-size:14px"><br></div><blockquote style="border-left:3px solid rgb(200,200,200);border-top-color:rgb(200,200,200);border-right-color:rgb(200,200,200);border-bottom-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div style="font-family:Arial,sans-serif;font-size:14px">I'd like to first express my disappointment with the
amount of drama this letter has caused.<br></div></blockquote>
<div style="font-family:Arial,sans-serif;font-size:14px">
<div>
</div>
<div>
</div>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div style="font-family:Arial,sans-serif;font-size:14px">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.</div><div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div style="font-family:Arial,sans-serif;font-size:14px">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.<br></div><div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div>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".</div><div><br></div><div>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 </div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><blockquote style="border-left:3px solid rgb(200,200,200);border-top-color:rgb(200,200,200);border-right-color:rgb(200,200,200);border-bottom-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div>It quite literally merely
asks Core contributors to put this proposal on their agenda with
some urgency.</div></blockquote><div><br></div><div>This is incorrect and misrepresenting the content of the letter. It specifically asks, i'm quoting "integration of CTV (PR <a href="https://github.com/bitcoin/bitcoin/pull/31989" target="_blank">#31989</a> 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 <strike>all</strike> 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.<br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><blockquote style="border-left:3px solid rgb(200,200,200);border-top-color:rgb(200,200,200);border-right-color:rgb(200,200,200);border-bottom-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div><span>Given that only a handful of Core contributors had thus far participated in the conversation on the proposal elsewhere</span><br></div></blockquote><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">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 <a href="https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/37?u=antoinep" title="previous CTV discussions went" target="_blank">previous CTV discussions went</a> wasn't enough.</div><div><br></div><blockquote style="border-left:3px solid rgb(200,200,200);border-top-color:rgb(200,200,200);border-right-color:rgb(200,200,200);border-bottom-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div>it
seemed like a suitable next step to communicate that we want Core
contributors to provide their position within this conversation<br></div></blockquote><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">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.</div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">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.<br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Best,<br>Antoine Poinsot<br></div><div>
On Tuesday, June 17th, 2025 at 7:31 AM, Steven Roose <<a href="mailto:steven@roose.io" target="_blank">steven@roose.io</a>> wrote:<br>
<blockquote type="cite">
<p>Hey all</p>
<p><br>
</p>
<p>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.</p>
<p>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.<br>
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.<br>
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.<br>
</p>
<p>On the proposal itself. I have heard some mentions of TXHASH and
why we, as the developer community, wouldn't go straight for
TXHASH.</p>
<ul>
<li>I think TXHASH is too far from being ready at this point:<br>
</li>
<ul>
<li>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.</li>
<li>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
<a href="https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760" rel="noreferrer nofollow noopener" target="_blank">https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760</a>)</li>
<li>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.<br>
</li>
</ul>
<li>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.<br>
</li>
<li>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.<br>
</li>
<li>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.</li>
<li>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.<br>
</li>
</ul>
<p>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. </p>
<p>That being said, I'm in no way married to the exact details of
the proposals.<br>
</p>
<ul>
<li>I am sympathetic to worries of changing legacy/v0 script. I
failed to convince myself of any valuable usage for bare CTV.</li>
<li>I am sympathetic to the consideration of revisiting scriptSig
and annex-related modifications to the template hash.<br>
</li>
<li>I am sympathetic to the decision to optimize better for the
rebindable signature use cases, meaning:<br>
</li>
<ul>
<li>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</li>
<li>the addition of an INTERNALKEY opcode, saving an additional
33 bytes for the rebindable signature use case</li>
</ul>
</ul>
All of the above changes I think can be decided on with minimal
bikeshedding and still encompass the same semantics of the original
proposal.<br>
<p><br>
</p>
<p>Best</p>
<p>Steven<br>
</p>
<p><br>
</p>
<div>On 6/9/25 12:40, James O'Beirne wrote:<br>
</div>
<blockquote type="cite">
Good morning,<br>
<br>
A letter has been published advocating for the final review and<br>
activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and
OP_CHECKSIGFROMSTACK<br>
(BIP-348). <br>
<br>
The full text of the letter can be found at <a href="https://ctv-csfs.com" rel="noreferrer nofollow noopener" target="_blank">https://ctv-csfs.com</a>.
It is<br>
reproduced below.<br>
<br>
---<br>
<br>
To the technical bitcoin community,<br>
<br>
We believe that the best next step for bitcoin would be to
activate<br>
OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK
(CSFS,<br>
BIP-348). These opcodes enable functionality for a broad set of
uses<br>
that will allow bitcoin to preserve and expand its role as a
scarce,<br>
censorship-resistant store of value.<br>
<br>
While there are a few promising proposals to improve bitcoin at
the<br>
consensus layer which may someday be deployed, we believe that CTV
and<br>
CSFS are uniquely well reviewed, simple, and have been proven to
be both<br>
safe and widely demanded.<br>
<br>
CTV was first formalized in BIP-119 over 5 years ago. Despite many<br>
attempts at refinement or replacement, it has remained the most
widely<br>
preferred method for enforcing pregenerated transaction sequences
using<br>
consensus. It unlocks valuable functionality for scaling
solutions,<br>
vaults, congestion control, non-custodial mining, discreet log<br>
contracts, and more.<br>
<br>
CSFS is a primitive opcode that has been deployed to Blockstream’s<br>
Elements for at least 8 years. It represents no significant<br>
computational burden over bitcoin’s most often used opcode,
OP_CHECKSIG.<br>
It can be combined with CTV to implement ln-symmetry, a
longstanding<br>
improvement to Lightning. It also unlocks a variety of other use
cases.<br>
<br>
We respectfully ask Bitcoin Core contributors to prioritize the
review<br>
and integration of CTV (PR #31989 or similar) and CSFS (PR #32247
or<br>
similar) within the next six months. We believe this timeline
allows for<br>
rigorous final review and activation planning.<br>
<br>
This request isn't meant to suggest that these contributors
dictate the<br>
consensus process, but rather it is an acknowledgement that before
these<br>
opcodes can be activated, they must be implemented in the most
widely<br>
used bitcoin client.<br>
<br>
As application and protocol developers, we are convinced of the<br>
significant benefits that these changes would bring to end users
of<br>
bitcoin – even if only considering their use for layer 1 security
and<br>
layer 2 scaling solutions. We are optimistic that given the
limited size<br>
and scope of these changes in both concept and implementation,
they<br>
represent a realistic next step in the continuing and important
work of<br>
preserving bitcoin's unique promise.<br>
<br>
Signed, <br>
<br>
Abdel (Starkware)<br>
Andrew Poelstra (@apoelstra)<br>
Ben Carman (@benthecarman)<br>
Ben Kaufman (@ben-kaufman)<br>
Brandon Black (@reardencode)<br>
Brian Langel (for Five Bells)<br>
Buck Perley (@puckberley)<br>
Calle (Cashu)<br>
Calvin Kim (@kcalvinalvin)<br>
Chun Wang (f2pool)<br>
Christian Decker (@cdecker)<br>
Coinjoined Chris (Bitsurance.eu)<br>
Evan Kaloudis (for Zeus)<br>
fiatjaf (@fiatjaf)<br>
Floppy (@1440000bytes)<br>
Gary Krause (@average-gary)<br>
Harsha Goli (@arshbot)<br>
Hunter Beast (@cryptoquick)<br>
Jad Mubaslat (@champbronc2)<br>
James O’Beirne (@jamesob)<br>
Jameson Lopp (@jlopp)<br>
Johan Halseth (@halseth)<br>
Luke Childs (@lukechilds)<br>
Matt Black (for Atomic Finance)<br>
Michael Tidwell (@miketwenty1)<br>
Nick Hansen (for Luxor Mining)<br>
Nitesh (@nitesh_btc)<br>
nvk (@nvk)<br>
Owen Kemeys (for Foundation)<br>
Paul Sztorc (@psztorc)<br>
Portland.HODL (for MARA Pool)<br>
Rijndael (@rot13maxi)<br>
Rob Hamilton (@rob1ham)<br>
Robin Linus (@RobinLinus)<br>
Sanket Kanjalkar (@sanket1729)<br>
Sean Ryan (Anchorage)<br>
Seth for Privacy (for Cake Wallet)<br>
Simanta Gautam (Alpen Labs)<br>
Steven Roose (@stevenroose)<br>
stutxo (@stutxo)<br>
Talip (@otaliptus)<br>
mononaut (@mononautical)<br>
vnprc (@vnprc)<br>
<br>
-- <br>
You received this message because you are subscribed to the Google
Groups "Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com" rel="noreferrer nofollow noopener" target="_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com" rel="noreferrer nofollow noopener" target="_blank">https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com</a>.<br>
</blockquote>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com" rel="noreferrer nofollow noopener" target="_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io" rel="noreferrer nofollow noopener" target="_blank">https://groups.google.com/d/msgid/bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io</a>.<br>
</blockquote><br>
</div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com" target="_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4%3D%40protonmail.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4%3D%40protonmail.com</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/CALiT-Zr3KO0fw1_DCpDVvA1Z1aLrvM-HFtvdsyLKhXxWvR%3DhvA%40mail.gmail.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/CALiT-Zr3KO0fw1_DCpDVvA1Z1aLrvM-HFtvdsyLKhXxWvR%3DhvA%40mail.gmail.com</a>.<br />