From: Greg Sanders <gsanders87@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Date: Tue, 10 Jun 2025 06:19:59 -0700 (PDT) [thread overview]
Message-ID: <b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com> (raw)
In-Reply-To: <CAKaEYh+tLtzaqAcN26RLw3AeNhF6VYvMdKrQY6dfCdhYg2Ad3w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 12955 bytes --]
Sorry, this got very long at least for my standards.
I'd like to start off by saying I believe that Bitcoin is in good technical
hands regardless of how this shakes out. Good things take time and we've
learned a lot; let's continue doing so.
Before I dive into what I think needs to be answered for this proposal to
move forward, I'd like to respond to language in the letter to make sure
we're on a common understanding of the asks being given here.
> We respectfully ask Bitcoin Core contributors to prioritize the review
and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or
similar) within the next six months. We believe this timeline allows for
rigorous final review and activation planning.
This is the meat of the post. This seemingly dictates inclusion for
activation as a fait accompli. Is this intended? The most generous
interpretation is that it's an ask for rigorous review, with the explicit
intention that if there is broad technical consensus to activate, that
broader communication to non-technical world + activation discussions
occur. I'd like to think this this is especially a call for those who have
not spoken up, including those who have done the homework yet conceptually
disagree?
What efforts will be done by proponents to gather that feedback and make it
public?
Each co-signer should consider what feedback could be received that would
demonstrate lack of technical consensus. I think it's plain that there
isn't at least 100% excitement in the technical community for the proposal.
How much of this lack of enthusiasm stems from inattention vs outright
opposition?
> six months
What happens if this time runs out? Is this just an ask to have people take
a look within a "few months" and continue/cease work after depending on
results?
# Feedback on Effort
I grouped my specific feedback as larger conceptual concerns, specification
concerns, and deployment concerns. They don't need to be answered inline
here at this specific venue, but this is a synthesis of my hesitation about
the current effort, hopefully with some concrete actions that can be taken.
For sake of discussion:
"CTV" means "next tx" commitment capability, not BIP119 per se
"TXHASH" means CTV with many knobs for app devs to choose what to commit to
"CSFS" means what's on the tin (less wiggle room here for changes)
## Larger conceptual concern:
Given all the things we've learned over the lifetime of BIP119 and the
prior iterations, we need to consider "why here and not there". What's a
good stopping point for adding functionality to Bitcoin Script, when we
have essentially infinitely combinations possible and different strategies?
My mental model of where we should stop in terms of capabilities comes in
the form of:
"Why here and not there"?
- Why not just CTV?
- Why CTV + CSFS?
- Why not TXHASH + CSFS?
- Why not bucket of opcodes? "swiss army knife" approach
"MEVil" is one type of objection to generalized Bitcoin script
introspection. CTV+CSFS is not known to appreciably increase MEVil
potential. For the sake of argument, let's assume this dimension doesn't
matter, due to a mixture in technical/market realities, or ColliderVM is
deployed, or the deployment of based rollups on Bitcoin without any
softforks. In some of those cases we should deploy anti-MEV technology
regardless, but let's set that aside.
Everyone should consider these on their own but stating my own view to
start the conversation:
Why not just CTV? I think there is general agreement that CTV alone was
insufficiently exciting to enough of the technical community to be deployed
on its own. There are some cool usages without, but the complementary
nature of a straight forward CSFS capability is too much to overlook,
increasing the flagship use-cases substantially.
Why not TXHASH+CSFS? If the cost is a year of concentrated development to
do something better, we should just do it. We could easily as a community
decide that TXHASH (with CTV capabilities being baked in as a trivial
default mode thereof) is the thing we actually want and easily get the
design finalized within that timeframe. With TXHASH+CSFS we can let app
developers decide what they find important, versus the opinionated CTV
default, whatever that is.
Note that I'm not totally convinced by this argument in either direction.
Once we have TXHASH, there's really no reason to not have CAT (that's very
small too!), maybe big num math, perhaps direct introspection. Maybe
bllish, simplicity, or GSR? The community would have to agree on a stopping
point, and that seems like it could be difficult to do in a
short-in-year-terms timeline.
Why not bucket of opcodes? Same arguments apply on slippery slope but
moreso. There's no clear stopping point, turning it into a giant research
and engineering project, even if it's a good idea to start working on it
now.
## Specification concerns:
1. Why not commit to annex? I had considered future annex relay as
problematic for rolling out BIP119 due to its lack of commitment to the
annex field. Committing or not are both reasonable depending on usage. With
https://github.com/bitcoin/bitcoin/pull/32453 it at least won't impede
annex relay efforts unduly, so maybe this can be punted and CTV sticks
closer to it's minimalistic txid-stable design goal. Bringing this up
because few people seem to have considered this historically.
2. Legacy script support is not technically necessary for the capabilities
we desire. It considerably increases review surface for no known capability
gain and no known savings for protocols. Legacy scripting should not be
modified lightly, and if there's no strong motivation, it should be
abandoned in favor of solutions that don't touch it. See more discussion in
that direction here:
https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/75
2. BIP119 committing to other prevouts very indirectly is a surprising
anti-feature:
https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
This feature is proported to make specific BitVM constructions trustless in
one respect, instead of the 1-of-n trust assumption held. This is extremely
surprising, and as can be seen in the thread extremely brittle and ugly.
BIP119 activated alone seemingly incentivizes very non-standard scriptSigs
on legacy scripting, rather than directly offering the functionality
desired. This is a bad sign which either means we should ban it outright by
f.e. requiring scriptSigs to be blank, or take another long hard look at
TXHASH to give app devs tools they actually want such as TXHASH.
What other surprising capabilities lurk in BIP119 that would incentivize
deranged usage like this? Maybe nothing? Perhaps it's hubris to predict it
and we should just do TXHASH? Maybe this hack is not a big deal and I
shouldn't be physically repulsed by having to carve out a standardness rule
for it?
## Concrete Deployment concerns:
1. Summarize technical community objections and adequately address them in
a single discoverable location. I do not believe this has been done
adequately up until now.
2. Specification feedback fully addressed and discoverable in a single
location.
3. Flagship PoCs: At a minimum I would hope for some level of LN-Symmetry
PoC, and or perhaps proving out hArk(or Erk), and make sure they are
re-validated on whatever the final spec would end up being. If we want to
draw some lessons on taproot activation it should be that validation should
be done throughout the lifetime of the proposal, not early and then only
after activation.
I'm hopeful on this front but 6 months to get things like this done in
addition to everything else seems very short.
4. Second consensus implementation: It's important to validate the BIPs and
gather more design feedback before finality of spec. Again, let's learn
some lessons from past mistakes. Can btcd get a branch up and running that
matches the specs and bitcoind?
On Tuesday, June 10, 2025 at 5:52:27 AM UTC-4 Melvin Carvalho wrote:
>
>
> út 10. 6. 2025 v 1:11 odesílatel Andrew Poelstra <apoe...@wpsoftware•net>
> napsal:
>
>> Le Mon, Jun 09, 2025 at 04:40:52AM -0700, James O'Beirne a écrit :
>> > Good morning,
>> >
>> > A letter has been published advocating for the final review and
>> > activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK
>> > (BIP-348).
>> >
>> > The full text of the letter can be found at https://ctv-csfs.com. It is
>> > reproduced below.
>> >
>>
>> Hi all,
>>
>>
>> James, thanks for posting the letter. Matt, Antoine -- thanks for
>> replying quickly and respectfully even though you disagree with its
>> contents. Let me try to clarify my stance and why I signed onto the
>> letter.
>>
>> First, the specific choice of CTV + CSFS would not be my first choice
>> on technical grounds. But what I'd like to see is something that is
>> technically "good enough" to enable vaults and some new script usecases,
>> while avoiding things that are politically toxic (which seems to be
>> pretty-much everything, but maybe right now does not include CTV+CSFS?).
>>
>> So any arguments about CTV+CSFS on the technical merits I think are
>> great and within the purview of "review and integration" that the letter
>> talks about. (The word "final" I think is too strong and in retrospect
>> I think we should've dropped it. But it's super difficult when writing
>> these things to identify which specific points of language need to be
>> changed.)
>>
>>
>> Second, regarding the ultimatum language -- it was quite difficult to
>> strike a balance between "Core consists of volunteers working on their
>> on projects, with no obligation to anybody, and certainly no obligation
>> to drive forward consensus changes" and "this is a letter that says
>> nothing substantial at all".
>>
>> The message that I want to communicate is: Bitcoin Core, like many
>> stakeholders, can veto any consensus changes because there will never be
>> a large enough contigent of the Bitcoin community confident to rush in
>> where angels dare to tread. But furthermore, if nobody in Core wants to
>> engage at all with consensus changes, then the result is effectively the
>> same as a veto.
>>
>> Therefore, if we want to see an increase in script expressivity, somebody
>> on the Core team needs to help champion it. (There's no one in particular
>> I imagine this "somebody" to be, and I suppose you could accuse me of
>> hypocrisy since I'm not volunteering myself, even though I have the
>> social and technical knowledge to help. It could be, and probably would
>> have to be, somebody who isn't currently active on Core. But it needs to
>> be somebody willing and able to work within the Core review process, to
>> deal with ongoing rebases, etc.)
>>
>>
>> Third, I really really hope that this letter does not lead to further
>> brigading or twitter fights or whatever bleeding into the Github repo.
>> (This is the one point where I think that my fellow cosigners agree with
>> me fully.) But on the other hand, I don't think that I personally should
>> shy away from discussion to mitigate that risk; it needs to be mitigated
>> by more agressive moderation or by higher barriers to entry for people
>> posting on Core PRs.
>>
>
>
> Andrew, would you agree with this premise?
>
> Bitcoin changes must be demonstrably proven safe, needed, and wanted
> before adoption. Proposers bear the burden, not the community. If the
> benefit doesn't demonstrably outweigh the risk, the answer is simple: don't
> fork the rules.
>
>
>>
>>
>>
>> Best
>> Andrew
>>
>>
>>
>>
>> --
>> Andrew Poelstra
>> Director, Blockstream Research
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>> -Justin Lewis-Webster
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bitcoindev+...@googlegroups•com.
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/aEdoIvOgNNtT6L4s%40mail.wpsoftware.net
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 16060 bytes --]
next prev parent reply other threads:[~2025-06-10 13:32 UTC|newest]
Thread overview: 33+ 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-10 23:42 ` Antoine Riard
2025-06-11 13:52 ` Peter Todd
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 [this message]
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 2:06 ` Greg Maxwell
2025-06-12 3:23 ` James O'Beirne
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=b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com \
--to=gsanders87@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.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