Delivery-date: Tue, 10 Jun 2025 13:33:48 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99;
Message-ID: <1147a254-5033-4663-99f0-7e98a5b6b6c0@mattcorallo.com>
Date: Tue, 10 Jun 2025 13:17:07 -0400
MIME-Version: 1.0
Subject: Re: [bitcoindev] CTV + CSFS: a letter
To: Andrew Poelstra <apoelstra@wpsoftware.net>,
 "David A. Harding" <dave@dtrt.org>
Cc: James O'Beirne <james.obeirne@gmail.com>,
 Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <aEdoIvOgNNtT6L4s@mail.wpsoftware.net>
 <195051b7c393b9a28727e87647ac002b@dtrt.org>
 <aEgxuiy4dUo8sNkY@mail.wpsoftware.net>
Content-Language: en-US
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <aEgxuiy4dUo8sNkY@mail.wpsoftware.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


On 6/10/25 9:23 AM, Andrew Poelstra wrote:
> Le Mon, Jun 09, 2025 at 04:08:21PM -1000, David A. Harding a =C3=A9crit :
>>
>> Why do you think nobody in Core wants to engage at all with consensus
>> changes (or, at least, specifically the proposals for CTV & CSFS)?
>>
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> But the result, when everybody feels this way, is a lack of engagement
> from the project as a whole.

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

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

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

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

Of course sign-on letters do little to reduce the impact of Drama, only con=
tribute 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.
>=20
>> The usual purpose of an open letter is to generate public pressure again=
st
>> the target (otherwise, if you didn't want to generate public pressure, y=
ou
>> would send a private letter).
>=20
> 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.
>=20
> 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.
>=20
> 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 g=
iving a six-month=20
ultimatum is all the more likely to drive the incentives in the wrong direc=
tion, not the right one.=20
Asking individuals why they, personally, are not currently working towards =
script expansion changes=20
is probably much more illuminating, or asking "what would it take to convin=
ce you to work on these=20
kinds of changes".

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

The fact that several companies are working to build and deploy Ark-based p=
ayment systems is also a=20
large part of that - having a concrete application where the developers see=
 substantial gains (which=20
can be independently evaluated, at least once things are up and running, wh=
ich as I understand it=20
will be soon) with specific consensus changes is a strong motivator. Previo=
us attempts at getting=20
CTV activated largely (in my experience) failed to get people excited becau=
se the demonstrated=20
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 CSF=
S);
>> I wouldn't expect more pressure to achieve new results; rather, I'd expe=
ct
>> more pressure to create more frustration on all sides.
>>
>=20
> 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=20
this comment, honestly. Yea, there's no great way to "address all of Bitcoi=
n Core" at once, but that=20
doesn't mean most of the most prolific contributors don't go to regular con=
ferences, meetups, and=20
aren't responsive to personal messages (at least in some cases).

I imagine, maybe wrongly, but I imagine that nearly every substantial Bitco=
in Core contributor is at=20
least two conferences a year, and they're usually speakers so their names a=
re on the websites of the=20
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.
>=20
> 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.
>=20
>> Alternatively, if you feel like the lack of engagement is a result of so=
me
>> 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) woul=
d
>> help address it.
>>
>=20
> 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 o=
n the meaning of the "six=20
month" timeline :).

Matt

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
1147a254-5033-4663-99f0-7e98a5b6b6c0%40mattcorallo.com.