I think the easy way to do this is to expect both an implementation of the features in question, and an interesting MVP/demo of how those features can be used in practice. You then draw the line between a collection of features that's implemented and has useful demos, versus ones that aren't implemented or don't yet have interesting demos.

....
....

(b) there has been huge resistance to the idea of implementing demos of useful things on top of proposed features when that's brought up as something people might expect to see prior to feature activation

After discussing this further with Matt Corallo in another thread, I find myself agreeing with this perspective. It makes sense to require both actual implementation and convincing demonstrations as a way to move forward. However, creating these demonstrations is not an easy task. Although there are already written explanations for CTV + CSFS, the response to those efforts has left many supporters of these changes feeling unsure. They’re not confident that putting in more time and resources will lead to real progress.

The situation seems to split into two distinct groups. First, there are the smaller Bitcoin-focused teams (many of whom we know personally) that are resource constrained. These teams could leverage covenants in innovative ways, but they’re operating on tight budgets. For them, participating in this process can’t be a leap of faith; they need more assurance that their efforts won’t be in vain, especially given how long CTV (now with CSFS) has been in discussion (6 years!). As Tiero from ArkLabs put it: "@ArkLabsHQ might not even exist by the time a soft fork is implemented."

On the other hand, there are the large-scale custodians with significant resources at their disposal. These organizations could theoretically drive adoption, but even for them, the uncertainty around activation makes it a risky bet. Instead, they’ve opted for more predictable solutions, like establishing Trust companies, which provide legal guarantees and protections such as bankruptcy remoteness. While this approach is costly and time-intensive, it’s seen as a safer and more reliable path. We've already watched major players like NYDIG, BitGo, and ZeroHash go this route.

As a result, we’re in a tough spot. Those with the resources to contribute are prioritizing legal frameworks over engineering solutions, while smaller teams that could truly benefit from CTV are holding back to avoid jeopardizing their survival.

From my perspective, the CTV discussion has missed important steps, and instead of those steps being taken, advocates have been attempting to use public pressure to force adoption on an "accelerated timeline" pretty much continuously for at least three years now. I've tried to help CTV advocates take the steps I believe they've missed, but it's mostly resulted in silence or insults rather than anything constructive.

I went through the Bitcoin forking guide in detail and found it both impressive and incredibly useful. I’ve even put together a checklist inspired by it, which I’m actively using to ensure I’m covering every step thoroughly. This ties into the industry survey I mentioned earlier (something I’m genuinely excited about).

I’ve tried reaching out a few times via delving and Twitter DMs to get your feedback but haven’t heard back yet (I don't have your telegram or signal!). Since you seem open to sharing input here, I’d love to hear your thoughts on my approach. Your perspective would mean a lot!

Matt's already raised some specific issues in this thread that could be engaged with and resolved

I broke out in a private email thread to address his concerns. I'm bringing the core of our issues back to the main thread here (at the top of this email).

Thank you,

Harsha, sometimes known as arshbot

On Fri, Jun 13, 2025 at 2:19 AM, Anthony Towns <aj@erisian.com.au> wrote:

On Tue, Jun 10, 2025 at 01:23:06PM +0000, Andrew Poelstra wrote:
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).
There isn't really any place to send a "private" letter.
Here's one way to get a list of such places:
$ git log src/script/ | grep ^Author: | head -n10000 | sort | uniq -c | sort -rn | head -n20
I feel pretty sure you've got my telegram contact info too, if nothing else.
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.
I think if you're looking at it as "targeting" people, that's probably not going to be very constructive. It certainly comes across as an implied threat.
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.
I've written my perspective of what core's role in this should be
[0], and am happy to discuss that further if there's some way in which that approach falls apart. The approach proposed there doesn't require pressuring core for support.
[0] https://delvingbitcoin.org/t/bitcoin-forking-guide/1451
From my perspective, the CTV discussion has missed important steps, and instead of those steps being taken, advocates have been attempting to use public pressure to force adoption on an "accelerated timeline" pretty much continuously for at least three years now. I've tried to help CTV advocates take the steps I believe they've missed, but it's mostly resulted in silence or insults rather than anything constructive. At least from where I sit, this is just creating incentive problems, not solving them.
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
Asking for "integration" as well as review presupposes the outcome of the review, which doesn't come across as very respectful of the reviewers' opinions, for what it's worth.
To analogise to book publishing, there are two sorts of review one might undertake: if you're an editor or beta reader, when you review a book, you can engage with the author and suggest ways in which the book seems flawed and can be improved; on the other hand, if you're a columnist, the book is already published, and the only thing you can do is recommend whether the book is worth buying and reading or not.
If you're asking for the first sort of review, for that to be a success, you need an author or community that's willing to engage with criticisms, rather than, for instance, dismissing them in advance as bikeshedding. Matt's already raised some specific issues in this thread that could be engaged with and resolved, for instance, as has Greg Sanders. I don't think you've engaged with either, and while James has, it's only been to dismiss them.
If you really want this to be treated as final unchangeable proposal and just get a detailed "CTV+CSFS sucks, 0 stars, NACK" review that will inevitably be used to justify another round of "core are idiots who are killing bitcoin, we have to replace them now", I guess I can provide that; but I don't see a way of doing that while maintaining my
(already pretty shaky) assumption that "this is a serious proposal by serious people who are willing to engage with criticism and resolve problems with their ideas, they're just ... a bit over-excited and have other demands on their time right now I guess".
Cheers,
aj
--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/KJF6A55DPJ8/unsubscribe. To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aEvC_zT3TEsjxc9o%40erisian.com.au.