From: "James O'Beirne" <james.obeirne@gmail•com>
To: "David A. Harding" <dave@dtrt•org>
Cc: Andrew Poelstra <apoelstra@wpsoftware•net>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Date: Tue, 10 Jun 2025 10:03:23 -0400 [thread overview]
Message-ID: <CAPfvXf+0M2PPYOAuWNt9EFWBXGspkZ3xDXKb9Tm7MW8RO3X0aA@mail.gmail.com> (raw)
In-Reply-To: <195051b7c393b9a28727e87647ac002b@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 6440 bytes --]
Hi Dave,
> Why do you think nobody in Core wants to engage at all with consensus
> changes (or, at least, specifically the proposals for CTV & CSFS)?
For evidence of this, we need look no further than what the regulars of
the project themselves are saying. Mike Schmidt published the results of
the 2024 year-end Core contributors survey, and the aggregated answers
to "goals/priorities for 2025" were (https://archive.is/M8bln):
> - Cluster mempool completion and deployment +9
> - Enhanced wallet functionality +9
> - Testing infrastructure improvements +8
> - Security hardening initiatives +2
> - P2P layer improvements +2
> - Build system modernization +1
The "highlights from 2024" were also revealing
(https://archive.is/YNtcP). On both lists, questions of script
functionality or softforks are nowhere to be found, and this is
consistent with my personal experience in the project.
Another fact ready at hand is that while Core participants have dished
out a lot of soft, negative feedback about various proposals, or put
forth lofty posts about proposals of their own with no code (e.g. GSR,
TLUV),
they have written no code toward any of the workable proposals under
consideration. The single exception to this is instagibbs, who has
generated (valuable) code contributions toward VAULT, APO, and CSFS.
All prototyping and proposal construction have been done almost
exclusively outside of Core for the last 5 years.
---
More anecdotally, back when I was a regular (<2024) and casually talked
with some of the maintainers privately in Signal, there was open ridicule
for
developers (myself included) who would open pull requests related to
precursors for possible softforks.
As of just a few months ago, in a private Core signal group Antoine
Poinsot joked (presumably?) that if contributors simply let the recent
CHECKTEMPLATEVERIFY pull request[0] go unmoderated for a
week, the repo could close it on grounds of spam.
[0]: https://github.com/bitcoin/bitcoin/pull/31989
The message verbatim reads:
> Antoine Poinsot: At this point we could even just suspend moderation,
> all mute this thread, come back to the firehose in a week and have
> enough ground to close the PR.
Most attendees from the last CoreDev event should be able to attest to the
faithfulness of this transcript.
This instance, in conjunction with the fact that Poinsot is probably the
most active Core regular (of 2 or 3) actively engaged in covenants
discussions now, is not grounds for optimism for me personally.
This is all to say nothing of the reception that Jeremy Rubin was given
by Core regulars during 2020-2024.
Project internals aside, the plain fact is that despite changes that
have been stable for many years and significant community support, the
Core project does not feel meaningfully closer to merging even precurors
(e.g. regtest-only implementation) to improvements in script
functionality today than it did 3 years ago.
The more senior contributors in Core used to swap emails about
graftroot and APO (circa 2018), but now the major output from the
project seems to concern itself with policy, mempool design, performance
optimization, build systems -- areas that are much more permanently
malleable and (while important) are ultimately less impactful than
consensus changes.
From the standpoint of an informed outsider, it matters not so much
*why* there hasn't been progress, but simply that there hasn't been.
It doesn't really matter where the blame for this lays. What
does matter is addressing it. In my view, clearly broadcasting a
widespread desire among technical stakeholders to see a shift in focus
on the part of the de facto monopoly project seems like a necessary step
for "outsiders" of the project who are concerned about the lack of
progress.
> The usual purpose of an open letter is to generate public pressure
> against the target (otherwise, if you didn't want to generate public
> pressure, you would send a private letter).
I think there's somewhat of an excluded middle here.
While there could be many reasons for this letter, I would guess that
one of the most widely shared among the co-signers is that a public
letter of this sort creates the opportunity for a technical Schelling
point around the proposal. It demonstrates publicly and in one place
that there is considerable support among the technical bitcoin
community, and it creates a single "working draft" that can be built
around.
Many of the signers are builders capable of evaluating the proposals,
but don't necessarily have the time to opine on Delving threads or write
prototypes because they are, well, building things for actual end use.
This letter gives them a substrate to express an informed technical view
without having to construct from whole cloth a way to do that. As we all
know this takes time and is, in the case of bitcoin, fraught with social
peril.
So one of the core functions of the letter is as a single way that
engineers can demonstrate a unified agreement on a plausible
next step, and the letter exists as a public artifact of that consensus.
My own thinking was that such a unified statement would be a valuable
signal for Core contributors, indicating that a lot of the ecosystem is
serious about these changes. This creates a kind of "pressure" perhaps,
but it's the same kind of "pressure" that is created when consumers
demonstrate to a company that there's demand for a product.
The letter serves a few functions, but this optimistic one is
likely the most widely shared.
All that said, one of my personal goals in the letter, not shared by all
co-signers but likely many, is to clearly indicate dissatisfaction with
the observable status quo as of the last few years.
A few people who have suggested "if that's the case, instead of a letter
why not just release an activation client?" I think we all know how that
would have been received. This letter is a less drastic move that both
unambiguously signals dissatisfaction but stops short of acting rashly
and ineffectively.
Warm regards,
James
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPfvXf%2B0M2PPYOAuWNt9EFWBXGspkZ3xDXKb9Tm7MW8RO3X0aA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7536 bytes --]
next prev parent reply other threads:[~2025-06-10 15:23 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 [this message]
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 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=CAPfvXf+0M2PPYOAuWNt9EFWBXGspkZ3xDXKb9Tm7MW8RO3X0aA@mail.gmail.com \
--to=james.obeirne@gmail$(echo .)com \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=dave@dtrt$(echo .)org \
/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