Antoine Poinsot

CVE-2025-62860: thousands of Bitcoin nodes disabled DoS protection

Tue, 10 Nov 2026 00:00:00 +0000

In September 2025, Martin Zumsande stumbled upon a bunch of misbehaving Bitcoin Knots nodes. This led us to discover a widespread configuration bug which exposed Bitcoin Knots and Bitcoin Core nodes to privacy leaks and various DoS vectors.

It already feels far away, but until not too long ago Bitcoin was targeted by a campaign of disinformation and harassment to promote a misguided fork coin. This all started when a group of Bitcoin enthusiasts, vocal on social media, objected to a default relay policy change in Bitcoin Core. They decided to turn to Bitcoin Knots as an alternative, at the time still merely a fork of Bitcoin Core’s software, not yet of the Bitcoin network.

Some seized on the discontent to politicize Bitcoin’s reference implementation development process, using the all-too-effective tactic of Accusation in a Mirror, amplified by social media. Others fueled the controversy through virtue signaling or attention seeking, seemingly unaware of the harm they were causing.

For context, September 2025 was around the release of Bitcoin Core 30, just before the publication of the consensus change later enforced by Knots. On the mass psychosis timeline, we’re right in the middle of the “Bitcoin Core v30 will insta-kill Bitcoin with CSAM” narrative. We are past accusations of Bitcoin contributors being pedophiles and the release of deepfake sexual videos targeting one of them, just not quite yet at the justification of a “temporary” emergency confiscation fork or one of Bitcoin’s most productive contributors in recent years quitting over personal attacks.

During this period, the meaningless “node count” metric was a central talking point of Knots promoters. While this count was artificially inflated for social media campaign purposes, a non-trivial chunk of them were simply that of people discontent with Bitcoin Core’s relay policy. Intrigued, my (then) colleague Martin figured a lower bound could be established pretty easily.

Bitcoin nodes gossip about other nodes they know of to help peers discover each other. A peer can request a sample of these addresses using a GETADDR message. To limit how much information about the network topology can be gathered this way, Bitcoin Core caches its responses to GETADDR for 24 hours, returning the same set of addresses to repeated requests instead of revealing new ones each time.

This also provides a convenient way to detect Sybils: if multiple advertised nodes return the exact same cached response, they are likely instances of the same underlying node. Counting these duplicates can therefore establish a lower bound on the number of fake nodes. In running this experiment, Martin unexpectedly discovered that the vast majority of Knots nodes on Tor did not cache their GETADDR responses at all!

Martin mentioned this discovery to me, and I started investigating the diff between the Knots release and its Bitcoin Core counterpart. Surely, I thought, the bug must be somewhere among the many unreviewed changes Knots had made to Bitcoin Core. Turns out there was indeed a bug hiding in there, but this was only part of the story…

After a couple hours of investigations, myself and another colleague failed to find what could cause this misbehaviour, and failed to reproduce it. Eventually, we decided the side quest was not worth it and went back to work. Before calling it a day though, Martin let a more comprehensive experiment run overnight, which revealed something interesting… Only the Knots plus Tor combination was affected: the vast majority of Knots nodes on clearnet, and Core nodes on either network, did cache the response to a GETADDR.

When checking the result of the experiment the next day, we struggled to make sense of it. Not only was the bug specific to Knots, it was also specific to Tor, and we couldn’t reproduce it locally.

Martin also mentioned that the distribution of Knots nodes is heavily skewed towards Tor, contrary to that of Core nodes. This is what prompted his Sybil investigation in the first place, as Tor identities are free to create. However I pointed that this distribution could simply be explained by the commercial success of some Knots turnkey solution. That’s because turnkey node-in-a-box solutions commonly (ab)use Tor as a VPN for remote access behind a NAT.

From past experience, I also knew such solutions set the whitelist configuration, because some of the apps they bundle need it (for bloom filters, or privileged p2p access). Could it be?.. BINGO! Start9 whitelisted all of localhost, which included the Tor daemon. Bitcoin Core and Bitcoin Knots would apply the whitelist by treating inbound Tor connections as coming from the IP of the Tor daemon. Bitcoin Knots lifted more protections by default for whitelisted peers, including the ADDR caching privacy leak mitigation, which is what made this issue observable there.

While it was made worse by, and only visible on, Knots, it is important to highlight this issue affected all users of Bitcoin Core and Bitcoin Knots that configured -whitelist with an IP range that included the Tor daemon used by their node. This is a non-default configuration that was surprisingly widespread. All turnkey node solutions I knew of were affected, and high profile projects like Electrs or BTCPayServer recommended setting -whitelist in their documentation.

Therefore the misbehaviour observed on hundreds of Bitcoin Knots nodes was actually a symptom of something far more widespread, and concerning. With -whitelist set to the IP range of the Tor daemon, your node would lift various DoS and privacy protections for all incoming Tor peers. This meant that affected nodes could be trivially DoSed and footprinted.

We chose not to probe nodes to get the total number of affected nodes. That can be extrapolated from the Knots numbers though, where 80% of ~3.5k nodes were demonstrably affected. About twice as many Core nodes were running behind Tor, and even if we conservatively estimate a third of which to be turnkey setups, the total is already about 5,000 affected nodes.

We alerted the Bitcoin Core security team on September 12. Because the vast majority of Knots nodes were affected, we also notified Luke Dashjr. This was a gamble, given his ongoing personal attacks against Bitcoin Core contributors and the conspiracy theories he was spreading about the project. His affiliates had also made legal threats against mining pools running Bitcoin Core. We were worried he might end up exploiting the vulnerability to spread more FUD about Bitcoin Core, justifying such an attack through the same narrative he had built around the project to rationalize his behaviour and, eventually, his fork coin.

I messaged Luke on September 17. He acknowledged receipt the same day and signaled he would respect the embargo period. To his credit, he has as far as I know not broken the embargo nor tried to exploit this vulnerability to his benefit. He even offered to credit me publicly on responsibly disclosing a security issue to Knots, when the discourse shifted to “Bitcoin Core uses its security policy to push CSAM on its users” (it’s embarrassing to write such a ridiculous statement, but it’s important to remember how low parts of our community had fallen during that time). I declined, as I figured it unnecessarily risked revealing the vulnerability before many users had the opportunity to patch their node.

Bitcoin Core fixed the surprising behaviour of applying the whitelist to inbound Tor peers in PR #33395, which shipped in 28.3, 29.2 and 30.0 a month later. But projects did not need to wait for a Bitcoin Core release to distribute a patch to their users. In fact, indiscriminately whitelisting an entire IP range by default is pretty risky to start with. For a security critical project, it’s preferable to block everything by default, and only make pinpointed exceptions.

But this is much less flexible, and turnkey nodes may not know what IP address future whitelist-requiring applications will use. Bitcoin Core offers an option that can prevent the footgun without losing too much flexibility: -whitebind. By using this option you make your bitcoind listen on additional ports (presumably on a loopback address). This can be used to give more fine grained permissions (for instance none on port 8333, “noban” on port 9333, “bloomfilter” on port 10333, etc..) and make it harder to misuse: presumably a proxy for untrusted peers would be configured to connect to the default port, and wouldn’t silently give peers additional permissions simply by virtue of running a local daemon. This was the approach used by nix-bitcoin, a node-in-a-box solution that was not affected by the vulnerability.

I reported this issue to various affected projects that were shipping software directly to end users. I contacted Nix-Bitcoin, Start9, Umbrel, Raspiblitz, Nodl and MyNode. Nix-Bitcoin had already discovered and patched the issue in 2021 (see above). Start9, Umbrel, Raspiblitz and Nodl were responsive. All of them promptly implemented a mitigation and shipped it to users. MyNode was a bit harder to reach, but they eventually shipped a fix (approximately a month later). I also shared the issue with Nicolas Dorier, since BTCPayServer requires a whitelisted connection for its indexer to work properly. He checked and told me their Docker configuration, which is the recommended way of deploying BTCPayServer, was not affected.

The details of the vulnerability have just been published by the Bitcoin Core project in a security advisory, following its security disclosure policy.

As of November 2026, most nodes have upgraded to a Bitcoin Core version that contains the mitigation. 13% of reachable peers are still running a version without the mitigation behind Tor, which could be vulnerable if configured with a whitelisted IP range that includes the Tor daemon. Out of those, 80% run version 28 or earlier, which have been EOL for 6 months or more and are already affected by publicly disclosed vulnerabilities, some of them high-severity.

To conclude, this is not the most exciting security vulnerability I’ve been involved in reporting (or patching), but it’s certainly one where the embargo period felt the most awkward. There was something surreal about coordinating a responsible disclosure with Luke, who was perfectly reasonable in our private exchanges while continuing his attacks on Bitcoin Core contributors in public. And there was a certain irony in watching those who had turned their preference for Knots into a campaign against Bitcoin Core and its contributors post about upgrading to the latest Knots release to “own” Core developers, unaware that the update protected them from a vulnerability responsibly disclosed to Knots, and fixed, by those very developers.

Quantum threat: let's not turn Bitcoin into an altcoin

Fri, 05 Jun 2026 00:00:00 +0000

Cryptographically Relevant Quantum Computers are an uncertain, existential threat to Bitcoin. Discussions about addressing this issue raise fundamental questions about the nature of Bitcoin, as a consensus system and as a currency. Some trends in the discourse around this issue concern me, so naturally i figured one more blog post would fix that.

I believe there is something that sets Bitcoin apart from technically similar competing alternatives. Apparently, so does the market. The reason for this boils down to network effects: people believe Bitcoin is useful because other people believe Bitcoin is useful. And the cornerstone of usefulness is reliability: most people expect to be safer storing value in Bitcoin than in any of the competing alternatives. I believe this expectation largely matches reality, but the way Bitcoin approaches the CRQC threat could drastically change this.

Two possible responses to this risk could undermine trust in Bitcoin so severely as to make it indistinguishable from an altcoin. The first one is that a large portion of the userbase gets their coins stolen, as that would be a fatal blow to network effects. The other one is that the vast majority of the economy coordinates to pre-emptively freeze other people’s coins, deemed to pose a systemic risk if a CRQC materializes, as that would directly undermine Bitcoin’s value proposition. It is important to stress that the latter is not merely an ideological position: confiscation being impractical is the whole reason why users trust Bitcoin to have value in the first place. Break this trust, and you’ll eventually lose the network effects.

These failure scenarios may only be avoided if the vast majority of Bitcoin users have migrated to post-quantum output types by the time, if ever, the Bitcoin economy believes a CRQC will imminently materialize. Therefore a migration strategy should attempt to maximize the number of individual users upgraded before Quantum Panic day (QP-day?). This is an enormous undertaking, because most Bitcoin users are not active Bitcoin enthusiasts or companies. They don’t keep up with the latest developments, rarely move their coins, and even more rarely upgrade their custody setup. This means that in the scenario where a CRQC eventually materializes, migration must take place during the period of uncertainty, as once we knew for sure it was going to happen it would already be too late to migrate the long tail of Bitcoin users.

To make matters worse, the PQ signature scheme would itself be more cumbersome to use and several common practices that underpin today’s Bitcoin usage would be unavailable¹. This is a typical collective action dilemma: everyone would greatly benefit from everyone migrating (in the event a CRQC does materialize), yet every individual’s benefits to unilaterally migrate are low² and associated costs are high. In light of this, i think it’s useful to classify migration strategies in two categories: strategies whose costs are borne individually vs strategies whose costs are borne collectively.

In the first category i would include P2QR³, an output type that makes a PQ signature scheme available exclusively. This maximizes the (limited²) individual benefits if CRQCs become a reality, as it guarantees the owner retains access to his coins on any chain that survives. It is also the only option that is effectively a full migration, which is useful in avoiding “marketing upgrades” whereby a service provider adopts the official PQ migration output types while still leaving its users dependent on EC security assumptions⁴. Of course, the downside of this approach is that individual users must bear the costs of upgrading long before anyone knows whether it is at all necessary. This strategy therefore does not satisfactorily address the “long tail” problem.

In the second category i would include P2TRv2⁵, which prescribes introducing a Taproot clone with a PQ signature scheme available in leaf scripts, so users can attach a PQ escape hatch to their coins at no cost, to later complete the migration by disabling EC operations in this output type if/when the CRQC threat materializes. Because it is no more expensive to use, wallets would start defaulting to this output type and progressively migrate the long tail of users over the next ~decade⁶. As time passes, more information about the progress of CRQCs can guide the next steps.

This strategy embraces the fact that we simply do not have a good replacement for EC-based signatures. Making access to CRQC resistance depend on introducing significant friction in (or giving up entirely) established workflows and use cases will lead to users not migrating until the CRQC threat materializes. This would not give the long tail of Bitcoin users enough time to migrate before QP-day and therefore leave the system vulnerable. Since Bitcoin still systemically relies on EC security unless the vast majority of users migrate, P2TRv2 leverages Taproot’s hidden spend path feature to eliminate the individual costs of opting into the migration, and lets its completion be a later consensus change.

And even if we had a good replacement for EC cryptography, the P2TRv2 strategy would also shine on two fronts. First, it defers the step that comes with more downsides for Bitcoin until the CRQC threat becomes less speculative⁷. This is important even if you are convinced CRQCs are coming, because a more consensual first step may let the migration begin sooner. Secondly, it allows the work of porting to the new signature scheme the wide range of protocols, standards and use cases that can be salvaged to proceed in parallel with the migration period.

Why not do both then? On the surface, this seems compelling: those who can afford to fully migrate to the more cumbersome PQ scheme today can, and others who prefer to opt into the escape-hatch solution can as well. Yay, more optionality! Well, not really. One of the options is critical to the success of the migration, since it gives a chance to migrate the long tail of users, while the other one is more of a nice to have. Actually the more credible EC disabling in P2TRv2 becomes, the more the P2QR strategy becomes a waste of onchain space rather than a nice to have. And having the P2TRv2 output type as the Schelling point of the migration virtually guarantees that EC operations will be disabled in this output type: otherwise literally every active user risks losing their funds. Thus having P2QR as a second option alongside P2TRv2 would only create more risks by weakening P2TRv2 as the Schelling point of the migration.

Various alternative strategies have been proposed based on the P2MR output type. First introduced in the 8th revision of BIP 360, P2MR is a clone of Taproot but without the key path spend. I will discuss here the strategy i have seen most widely defended by proponents of P2MR: doing BIP 360 alongside the introduction of a PQ signature scheme as a Script operand. The motivation is similar to that of P2TRv2: let users commit to a PQ spend path while still being able to use the cheaper EC spends. The big difference is the removal of the key path in an attempt to mitigate “long range” attacks. This difference unfortunately makes migration more expensive by about 15%⁸ and preemptively gives up the Taproot incentive structure, key feature of the last Bitcoin upgrade. I believe this is the wrong tradeoff.

The long-range vs short-range distinction is at the heart of the debate around the PQ migration strategy. I believe most of the disagreements come down to whether we should see this distinction as meaningful. From the point of view of an individual Bitcoin user, it certainly is meaningful: in a world where your public key becomes a secret, sharing it on a global public broadcast network clearly will increase your risk. But this does not mean that the distinction is meaningful when considering the Bitcoin system as a whole. Public keys are already assumed to be, well, public throughout widely adopted workflows. Users trust that the discrete logarithm problem is hard when their hardware wallets share their xpub with online devices, when their wallet software shares their xpub or output descriptor with their wallet provider, when they share their xpub with a payee, when they publish a silent payment address or a paynym, when they reuse or spend from a hashed-pubkey address, etc.. In these conditions, whether some users have their public keys hashed onchain before spending time is irrelevant to the PQ migration of the Bitcoin system.

To fully migrate Bitcoin away from relying on EC security, the P2MR strategy would therefore need to be complemented by a later disabling of EC operations, just like P2TRv2. But besides making it more expensive for users to opt into the migration output type, it also incentivizes using it for purposes other than PQ migration. This makes it harder to believe that 1) enough users would migrate in the first place and 2) the EC disabling would in fact happen, since it would raise confiscation concerns. For these reasons, and because i don’t think we should downgrade Bitcoin until CRQCs materialize, i think P2TRv2 is a superior solution to P2MR.

In conclusion, the goal of a PQ migration should be to allow Bitcoin as we know it to survive a break of the discrete logarithm assumption. Transforming Bitcoin into yet another altcoin by permitting widespread theft, or by enabling confiscation, is not an interesting goal. The major challenge is that each individual Bitcoin user would strongly benefit from everyone else migrating, while migration itself is individually costly and would need to begin long before we can be reasonably certain whether the CRQC threat will materialize. The P2TRv2 strategy addresses this issue by shifting the migration costs from individual users opting into using the new output type in the short term, to ~all Bitcoin users coordinating to update consensus rules in the medium to long term. And P2TRv2 variants that allow users to avoid revealing their public key onchain before spending make, in my view, the wrong set of tradeoffs.

Mikhail Kudinov and Jonas Nick, “Hash-based Signature Schemes for Bitcoin” ↩︎
Why should one migrate if nobody else does? One response may be to have coins available on an altcoin that bootstraps off of Bitcoin’s UTxO set, but it says nothing of the value of said coins on whichever chain survives. This also ignores another option available to many users: just selling (part of) their coins to hedge against the CRQC risk. ↩︎ ↩︎
I steelmanned the case for P2QR here, Pieter also previously suggested something like P2QR here. ↩︎
Since “Post-Quantum” is a valuable marketing label currently, and most of the costs associated with migration arise not from using a different output type, but updating all your workflow with the new signature type that does not rely on EC security, this seems likely to happen. ↩︎
First proposed by Matt Corallo here. ↩︎
This is possible because the vast majority of wallets use a single-key spending policy and follow BIP 32 to deterministically generate keys from a master key. This BIP 32 master key is itself derived from a seed using a hash function (the seed is itself generally derived from mnemonic words using BIP 39). This makes it possible to securely use a PQ key derived from the BIP 32 seed even if EC cryptography is broken. ↩︎
There are of course some downsides to this first step, such as introducing a new output type. But these downsides are marginal compared to those of alternative strategies, and also come with benefits in the case where CRQCs never materialize, such as having more users migrated to Taproot. ↩︎
Calculation based on a 2-input, 2-output transaction for a typical single-key spending policy. ↩︎

Misbehaving nodes investigation

Fri, 05 Sep 2025 00:00:00 +0000

In late June 2025, Eric Voskuil reached out to me asking about a weird behaviour he had observed on the Bitcoin network. Libbitcoin had started dropping peers which advertized an excessively off timestamp in their version message and they found that while most peers were within seconds, a handful were off by small amounts and a large number was behind by up to 5100 minutes. What’s more, all those peers were Bitcoin Core v27.1 or v27.2.

Now, to be clear, 5100 minutes is a lot. Bitcoin Core will reject block (headers) with a timestamp more than 2 hours in the future. 5100 minutes is 3.5 days behind: a node with a local clock so skewed will reject blocks when they are created. It would only catchup due to Bitcoin Core’s stale tip detection logic, 3.4 days later. Further, that all of them are running specifically (outdated) versions 27.1 or 27.2 is quite odd.

I of course suspected spy nodes. But it was not a very satisfactory answer. Any surprising behaviour could be attributed to a spy node, and i don’t see any reason for a spy to tell everyone their clock is days behind. And why would they alternate versions, but only between 27.1 and 27.2? Clearly that didn’t explained much. However Bitcoin Core dropped network-adjusted time in 27.0 and later cleaned up the relevant logic in 28.0. I figured it might be the case that a bug slipped through in the removal for 27 and was inadvertently fixed when this logic was cleaned up in 28. And the fact that we only noticed this bug for 27.1 and 27.2 nodes would be simply that all 27.0 nodes had upgraded to patch releases. That seemed pretty unlikely, but was the best hunch i could come up with off the top of my head.

A couple days later, Eric comes back with another oddity. This time, he notices a bunch of nodes that don’t honour the version message’s relay flag. The relay flag instructs a node whether it should announce transactions to the sender of the version message. Not respecting this flag is a protocol violation and will result in a disconnection, in Bitcoin Core or Libbitcoin alike. In Eric’s experiment Libbitcoin would always set relay to false and yet those peers would still announce it transactions. All of the misbehaving peers were Bitcoin Core version 25.0 or 25.1 (but never 25.2!). Again, weird. The announced transactions traffic appeared to be organic, it wasn’t someone trying to exploit something.

In both cases, these are nodes that are misbehaving but don’t appear to be particularly malicious. In both cases, the malicious nodes claim to be some outdated Bitcoin Core version, and in at least one of these cases we know it’s not true (Bitcoin Core will always honour the relay flag). Was it some script kiddy who modified a Bitcoin Core client without knowing what he’s doing? That seems highly unlikely as that’s 4 different versions and hundreds of nodes in total. Some proxy spoofing the version message of a Bitcoin Core node? For what purpose?

At this point my guesswork was hitting a wall, so i asked Eric for a sample of the specific IPs exposing this behaviour. Upon receiving the sample, trying to connect to a couple of those IPs using a Bitcoin Core node did not expose this behaviour. I reported back to Eric, hinting that it must be a bug in his implementation. After further testing Eric found out that the time reported by these nodes was cycling between different values, a correct ones and a few skewed ones. “Almost like it’s 4 nodes.” Hmm. By repeatedly connecting to those nodes, it was possible to observe the same behaviour with Bitcoin Core. I decided to start writing a script which would repeatedly connect to these IPs and collect their version messages.

I brought this up over lunch at Chaincode, as well as to Bitcoin’s Chief Data Enjoyer, @0xb10c. Pieter analyzed my IPs sample and remarked they virtually all belonged to the same AS, AS401199 dubbed “Bitprojects”. “Looks like pretty much 4 full /24’s.” Hmm. Meanwhile, @0xb10c shared some historical data he had about start_height, which was equally off. Interestingly, it made clear the divide between skewed clock / height and not was also between versions. He also mentioned that somebody else had reached out to him about these IPs, not because of the time offset but because the person noticed one of them took 13s to reply to a GETDATA. Finally, he had also noticed the cycling behaviour:

I looked a bit more at my data, and it seems that if you connect to an IP twice, you might reach a different node from time to time. At least it gives you a singificantly different start_height and timeoffset.

At this point it became clear Bitprojects was running misconfigured nodes with some sort of broken proxy in front of them. Most likely it was related to their “anycast hosting” service. I initially considered they may be running for each IP one correctly configured node and several misconfigured ones. But this wouldn’t explain how they fail to honour the relay flag in version messages. Or set NODE_NETWORK even for pruned nodes (another misbehaviour Eric noticed). So they must have some sort of buggy middleware in-between? It actually turned out that the set of IPs with skewed clocks and the set of IPs sending incorrect version messages were disjoint. I focused on the skewed clocks for now, the rest is a mystery for another day. To learn more about how they exactly screwed up the timestamp and height, i ran a Script which would connect 8 times in a row to every Bitprojects IP. For each connection it would collect the announced time and start height.

I ran this Script around block height 902950. In total i received 2951 version messages with a correct block height, 379 messages for block height 902577 (about 2 days and a half behind), 347 messages for block height 902446 (about 3 days and a half behind), 395 messages for height 902440, 388 messages for height 902435, 354 messages for height 902425, 363 for height 902409, 408 messages for height 902403, and a few outliers. The timestamps received essentially matched those values. Looking at the specific values returned per IP, although their behaviour wasn’t perfectly consistent, there was a clear pattern of returning a correct value about half the time, and when it’s skewed half the time it’s about 2 days behind and the rest of the time about 3 days behind. Here is an excerpt:

IP 203.11.72.225: 8 version messages
        Time '2025-06-27T10:55:12': 4 version messages
        Time '2025-06-24T01:06:34': 2 version messages
        Time '2025-06-25T05:33:20': 1 version messages
        Time '2025-06-23T22:08:14': 1 version messages
        Height 902950: 4 version messages
            2025-06-27T10:55:12
            2025-06-27T10:55:54
            2025-06-27T10:56:34
            2025-06-27T10:57:28
        Height 902425: 2 version messages
            2025-06-24T01:06:34
            2025-06-24T01:07:54
        Height 902577: 1 version messages
            2025-06-25T05:33:20
        Height 902440: 1 version messages
            2025-06-23T22:08:14

IP 203.11.72.226: 8 version messages
        Time '2025-06-27T10:55:06': 5 version messages
        Time '2025-06-23T22:08:33': 2 version messages
        Time '2025-06-25T05:34:40': 1 version messages
        Height 902950: 5 version messages
            2025-06-27T10:55:06
            2025-06-27T10:55:28
            2025-06-27T10:55:54
            2025-06-27T10:56:14
            2025-06-27T10:56:54
        Height 902435: 1 version messages
            2025-06-23T22:08:33
        Height 902440: 1 version messages
            2025-06-23T22:08:14
        Height 902577: 1 version messages
            2025-06-25T05:34:40

IP 203.11.72.227: 8 version messages
        Time '2025-06-27T10:55:12': 4 version messages
        Time '2025-06-23T22:08:13': 2 version messages
        Time '2025-06-24T01:15:23': 1 version messages
        Time '2025-06-25T05:34:01': 1 version messages
        Height 902950: 4 version messages
            2025-06-27T10:55:12
            2025-06-27T10:55:29
            2025-06-27T10:55:54
            2025-06-27T10:57:07
        Height 902435: 1 version messages
            2025-06-23T22:08:13
        Height 902403: 1 version messages
            2025-06-24T01:15:23
        Height 902577: 1 version messages
            2025-06-25T05:34:01
        Height 902446: 1 version messages
            2025-06-23T22:13:27

IP 203.11.72.228: 8 version messages
        Time '2025-06-27T10:55:12': 5 version messages
        Time '2025-06-24T01:15:24': 2 version messages
        Time '2025-06-25T05:34:01': 1 version messages
        Height 902950: 5 version messages
            2025-06-27T10:55:12
            2025-06-27T10:55:34
            2025-06-27T10:55:49
            2025-06-27T10:56:14
            2025-06-27T10:57:34
        Height 902403: 2 version messages
            2025-06-24T01:15:24
            2025-06-24T01:16:02
        Height 902577: 1 version messages
            2025-06-25T05:34:01

I eventually reached out to the Bitprojects maintainer, who was very responsive. They let me know the misbehaviour was due to a clock misconfiguration, and the nodes running out of resources. They said they would immediately pause the nodes until they can reconfigure them properly.

On relay policy and recent OP_RETURN drama

Thu, 01 May 2025 00:00:00 +0000

I recently emailed the Bitcoin development mailing list about lifting the restrictions on the use of OP_RETURN outputs in standard transactions. This triggered yet another shitstorm, which prompted me to lay down my thoughts on the topic as a blog post to minimize the time wasted arguing in parts on Twitter.

What is relay policy and why is it necessary?

Policy is extremely broad and refers to all the rules observed by the software when interacting with the Bitcoin P2P network. Examples include the organization of requests emitted to peers, delays in message processing, refusing to process blocks with a timestamp more than 2 hours in the future (compared to the system time), or refusing to process certain types of transactions. The object of recent drama is the latter. I will use the nomenclature from my Bitcoin Stackexchange answer on the topic and refer to the rules dictating the format of transactions in isolation as “transaction standardness”, which is a subset of “mempool policy”, itself considered a subset of “transaction relay policy”, finally a subset of “relay policy”.

Standardness rules exist for three main reasons. The first is as DoS protection. Your peers on the P2P network are not identified and some transactions are more expensive than others to process. An asymmetry between the cost of sending you an unconfirmed transaction (which is very small) and the cost for you to process it creates a DoS vector. Another reason for standardness rules is to provide upgrade hooks for soft forks. Invalidating a type of transactions in a soft fork that was already non-standard for a while gives more guarantees that a non-upgraded miner won’t include a newly-invalid transaction in a block, making soft forks significantly safer to roll out. Finally, standardness rules have also been used as a way to nudge behaviour toward a less harmful approach, or to mildly deter certain activities. For instance by standardizing OP_RETURN outputs, or discouraging data storage back when blocks were not full.

What are the current standardness rules?

An unconfirmed transaction will be dropped by Bitcoin Core if:

it’s invalid by consensus;
it is timelocked to any future block but the next block;
its version is anything but 1, 2 or 3;
it’s larger than 400k weight units;
it’s smaller without witness than 65 bytes;
any of its inputs has a too large or non-pushonly scriptSig;
any of its inputs spends a scriptpubkey that does not match any script template from a shortlist;
any of its inputs spends a legacy P2SH scriptpubkey which contains too many signature operations;
any of its inputs spends a Segwit P2WSH scriptpubkey which contains a too large witness script;
any of its inputs spends a Taproot output with a witness stack which contains an annex;
any of its inputs’ witness stacks contain a too large element;
any of its outputs has a scriptPubKey which does not match any script template from a shortlist;
if more than one of its outputs matches the OP_RETURN (“datacarrier”) template;
any of its outputs has a below-dust value;
it requires validating too many signatures overall;

What modification is proposed? Why?

I recently suggested lifting the restrictions on the usage of OP_RETURN outputs in standard transactions. “OP_RETURNs” are a provably-unspendable type of outputs that were made standard in response to the usage of regular output types to store data in the Bitcoin blockchain (that is, non-transaction data). The goal was to provide a less harmful but as convenient method to store the data, that good actors could pick up. This was successful. Along with the standardization of this new output type, the size of the associated data was limited as a mild deterrent against storing too much data.

Mild deterrent because these are otherwise valid transactions, that the node would accept as part of a block. Most of the public transaction relay network enforcing a policy of filtering too large OP_RETURN outputs could deter isolated demand for those, or nudge developers to design their applications to take these limitations into account. But it is ineffective to prevent this type of transactions from being used if there is significant demand for them. Worse, treating a widely used type of transaction as non-standard is actually harmful from both the perspective of a node runner (blinding them to part of the network activity) and that of the network at large (hurting optimistic block reconstruction).

For a long time, OP_RETURNs remained the primary mean for people to store a small amount of data onchain. A few years ago people started leveraging the Segwit discount and storing data into an input’s witness instead. This let them store more data at a lower cost. A trend started around this type of transactions, which became in high demand. In fact so much so that it became the main driver of block space demand for a while. Although this approach already permitted to store ~5000 times more data in a single standard transaction, the demand for inscription incentivized people to build private bridges to miners to bypass other standardness limits such as the maximum transaction size in order to store even more data.

We are now in a situation where Bitcoin Core’s restriction on the size of OP_RETURNs by standardness is not binding anymore. One can store ~5000 times as much data in a standard transaction by stuffing its witness. Private bridges to miners and alternative public relay networks were built that allow to store ~50k times as more data in a single transaction. In fact these alternative relays allow bypassing several of Bitcoin Core’s standardness rules, including the maximum size of OP_RETURNs!

While these restrictions are not binding anymore for whoever wants to store data onchain, they still unnecessarily restrict constructions with time-sensitive transactions. Protocol designers want those transactions to be standard for a good reason: they don’t want to rely on private bridges for security-critical transaction broadcast. Those transactions need to relay properly on the more censorship resistant public network. It was recently brought to my attention that Citrea faced this situation with their Clementine bridge. In their construction, a watchtower challenge transaction needs to both pass on 144 bytes of data and be confirmed as soon as possible. Since they are restricted to a single 80 bytes OP_RETURN output by Bitcoin Core standardness, they use two unspendable Taproot outputs to include the other 64 bytes of data. These Taproot outputs will remain unspent forever, and every single full node will have to keep them in its UTxO set forever.

In the specific case of Citrea, it’s unlikely that many of those outputs would end up onchain. But it illustrates a severe issue in Bitcoin Core’s standardness rules. Not only they do not provide binding constraints to prevent using the block chain to store arbitrary data, they also incentivize more harmful ways of storing data! This is why i proposed to drop those restrictions.

What about optionality? Do you hate freedom?

Peter Todd’s pull request to drop these restrictions also removes the accompanying startup options (-datacarrier and -datacarriersize). This was quickly picked up as a narrative by trolls in the thread as well as on social media: not only does Bitcoin Core changes the default, it takes its users hostage by preventing them to turn it back on!

This is obviously nonsense when you think about it for a minute. These options are one of the only knobs available to a user to tweak transaction standardness rules, let alone relay policy. Would it make sense for Bitcoin Core to provide startup options to tweak other aspects of policy? Should we add an option to let the user pick what transaction version should its node consider standard? An option to accept transactions that are timelocked up to N blocks in the future in its mempool? To disable wtxid relay? Obviously not. But why? And how do we think about it consistently?

For one, options do not come for free. They increase code complexity and cognitive load on the user. Additional load means reduced ability for the user to make an informed decision about every single option. So the question, really, is when should we have an option? I think the answer to that is “when we can reasonably expect users to have a good reason to change the default, and more so than for other options we could provide instead”.

According to this criterion we’ve established, what can we say of -datacarrier and -datacarriersize in a world where there is no restriction on OP_RETURNs by default? First of all defaults are sticky. The vast majority of people do not change the default, so we can’t really expect providing the startup option to have any global effect. The local effect of a user setting -datacarrier=0 or -datacarriersize=X on their node would effectively just be shooting themselves in the foot: they would willfully blind themselves to part of unconfirmed transaction activity. If they are a miner this could increase roundtrips for compact block reconstruction. If they are transacting, this would prevent them from seeing part of transactions they are competing with for block space.

Once the default is set to not impose restrictions on the use of OP_RETURN outputs, there is no reason for a user to change the default. Therefore i don’t think a startup option to do that should exist.

Freedom is good. Having a startup option for every single operation that pertains to relay policy is not that.

Is Bitcoin dead?

No.

Many have taken the opportunity of my proposal to grandstand on Twitter. They exploit gullible people by making wild claims about OP_RETURN outputs being an existential threat to Bitcoin. I hope my post made it clear it is not, but consider also this. If Bitcoin was so brittle that Core choosing to relay perfectly safe, inexpensive to validate, consensus-valid transactions would break it, it would be utterly uninteresting in the first place!

The ability of this parasitical group to reach this level of attention is really telling of what our community values. I hope bitcoiners start demonstrating more critical thinking and stop giving in to the latest conspiracy theory every 6 months.

Is Bitcoin Core compromised?

No.

You should be highly skeptical of anyone making this claim. It undermines Bitcoin’s long term success. Cultural incentives matter. It is about time that we stop tolerating nonsense and come back to a place where most of us value (proof of) work, ideas, and selflessness instead of overblown emotional reactions, unbacked wild claims and adhesion to various cults.

For more on Bitcoin Core i highly recommend Adam Jonas’ “Has Bitcoin Core lost focus?”.

CVE-2025-43707: out-of-bounds read in the Rust-Miniscript satisfier

Thu, 24 Apr 2025 00:00:00 +0000

On March 25, @Pythcoiner from the Wizardsardine team contacted me about a crash bug in Liana they had identified as coming from the rust-miniscript dependency. After investigating i identified the crash as coming from the library’s Miniscript satisfier, and found it could be triggered by an attacker.

The impact of this vulnerability is that an attacker could make a victim crash by getting them to satisfy a transaction spending a specially-crafted descriptor. In simpler terms, a victim could crash when “signing” a transaction that spends from a specific “wallet”. This is not critical (but still pretty annoying!) if you consider the victim as being a software running locally. But these are pretty common operations and it would not be surprising that an application running on a server publicly exposes them (for instance through BDK). There, an attacker exploiting this bug could prevent all users from accessing the service.

The bug itself is an out-of-bounds read in the Satisfaction::thresh() function. This code assumes that the size of the sat_indices vector is strictly superior to the threshold k. This is not always the case, as thresh(2,A,B) is valid Miniscript. Therefore trying to satisfy any thresh() fragment with a threshold k equal to the number of sub-fragments will trigger an out-of-bounds read in the sat_indices vector. It can be fixed with the following diff:

diff --git a/src/miniscript/satisfy.rs b/src/miniscript/satisfy.rs
index d141340..cca7051 100644
--- a/src/miniscript/satisfy.rs
+++ b/src/miniscript/satisfy.rs
@@ -1026,7 +1026,8 @@ impl<Pk: MiniscriptKey + ToPublicKey> Satisfaction<Placeholder<Pk>> {
         // For example, the fragment thresh(2, hash, hash, 0, 0)
         // is uniquely satisfyiable because there is no satisfaction
         // for the 0 fragment
-        else if !sats[sat_indices[thresh.k()]].has_sig
+        else if sat_indices.len() > thresh.k()
+            && !sats[sat_indices[thresh.k()]].has_sig
             && sats[sat_indices[thresh.k()]].stack != Witness::Impossible
         {
             // All arguments should be `d`, so dissatisfactions have no

I reported this issue according to rust-bitcoin’s security policy by emailing Andrew Poelstra on March 25th, who acknowledged receipt on the same day. Andrew and Sanket Kanjalkar came back to me a couple days later. They asked for a 4 weeks embargo on the details and silently fixed the vulnerability in rust-miniscript PR #798. The fix was then backported to the 12.x release branch and a 12.3.1 version was released on April 1st. They also responded to this incident by increasing the fuzz coverage of their satisfier.

I’d like to thank the Rust-Miniscript maintainers Andrew Poelstra and Sanket Kanjalkar for the swift reply and the no-bullshit communication throughout this report. Thanks to the Wizardsardine team, and @Pythcoiner in particular, for identifying the crash in the first place. Finally, thanks to Chaincode Labs for sponsoring my Bitcoin open source work.

Bitcoin Core scope, concretely

Thu, 13 Feb 2025 00:00:00 +0000

In my last two posts i presented Bitcoin Core’s prioritisation issues and then provided an answer to what the scope and goals of the Bitcoin Core project should be. Now what?

Well, it’s not like we are starting a new project from scratch where we could just begin enforcing the scope as we develop it. We are fixing things in flight, with users and developers that depend on or care about existing modules that would be out of scope. Although developers working in these areas should realize they impose a non-trivial cost on all the other contributors that don’t believe they should be a priority, just throwing shit at each other is not going to move things forward. Engaging with “just delete the GUI” or “just delete the wallet” is a non-starter.

On the other hand not doing anything is making a choice by default, the choice of continuous burden on everyone else and reduced overall software quality. This needs to be addressed if we want to keep Bitcoin Core the go-to full node client for Bitcoin users, but also to keep critical contributors motivated to continue working on the project.

The multiprocess project presents an opportunity in this regard. Separate bitcoin-node, bitcoin-wallet and bitcoin-gui binaries communicating through well-defined interfaces open the door to splitting the current project into 3. The contributors at github.com/bitcoin/bitcoin would focus on the Bitcoin Core node and release a bitcoin-node program, exposing JSONRPC and IPC interfaces. The contributors at github.com/bitcoin-core/wallet would work on the bitcoin-wallet process. The Bitcoin Core wallet releases would contain both the wallet and node processes, presumably with a wrapper to make it transparent to users. This project would release the equivalent of today’s bitcoind. Finally, the contributors at github.com/bitcoin-core/gui would develop and release the bitcoin-gui program, which would ship with the node and wallet. Similarly to the wallet it would presumably ship with a wrapper to abstract for the user the technicality of using multiple processes. Bitcoin Core the project would still announce and host the node, wallet and GUI releases at https://bitcoincore.org.

This approach would make it so Bitcoin Core still releases a wallet and a GUI while still reaping the benefit that developments in these areas don’t impact the workflow of contributors to the node project anymore. Of course, there is no free lunch. The maintenance, fix and update burden shifting out of the node contributors either means it will shift on to the contributors of the wallet and GUI project or that it won’t happen at all. This is arguably the entire point: we are currently trading off quality in the node for maintainance of these areas. I argue this is backward.

This could also be an opportunity for the wallet and GUI projects. There’s been little interest in contributing to the Bitcoin Core wallet in the past years, despite there being tremendous interest in working on Bitcoin wallets in general. For instance rust-bitcoin has never made so much progress, and BDK is a major success adopted by dozens of projects with probably millions of users altogether. They have a larger feature set, with the Bitcoin Core wallet still struggling to catch up even years after a feature has been largely adopted by the industry¹. I count at least two dozen active contributors across these two projects. Regarding the GUI, it’s hardly being developed at all anymore, with only 29 PRs merged in the past year². There’s been talk of revamping it forever (1, 2) but it has never really materialized. It would be reasonable for the wallet to have a lower review bar than the node, and for the GUI to have a lower one than the wallet, as long as it’s advertized to our users. This could enable these projects to iterate faster and make more progress. Surely, being in their own project shielded from the animosity of other contributors and with the ability to make progress could make working on these project more fun and attract new contributors. A larger contributor base could in turn lead to improved software quality and increased capacity to catch up with features.

Doing this raises a number of questions. What branch of the node would the wallet and GUI projects track? How do you split depends? What about the Guix builds? The shared code in src/common, src/util, src/crypto, in tests, etc? There may be non-trivial and non-ideal choices to make in the process but we should not overlook the benefits of this approach: we re-focus the main project toward its critical mission and we keep the wallet and GUI, possibly unleashing more progress in these areas.

See for instance PSBT v2, a BIP that Ava authored and is still not merged into Bitcoin Core after 4 years due to lack of review. Meanwhile Ledger started using it 4 years ago and it was merged in libwally 2.5 years ago then adopted by Core-Lightning 2 years ago. ↩︎
Running this command on February 12th 2025: git log --merges --grep "bitcoin-core/gui#" --oneline --since=2024-02-12 |wc -l. ↩︎

Stating the obvious

Wed, 05 Feb 2025 00:00:00 +0000

Following my post from a couple weeks ago, i set out to answer my own question.

How do we define a project scope? An interesting exercise is to consider what should be the bounds if we had near infinite resources. Should there be a limit in the scope of the project then? Surely you can think of examples of features we’d never want to include in Bitcoin Core (for instance a general purpose text editor, a browser, a recursive DNS resolver, ..). But then where do we draw the line? It’s tempting to say “at non-Bitcoin stuff”, but this is only begging the question. A message encryption feature (or even signmessage for this matter) can be argued to be Bitcoin-related as much as a DNS resolver.

I think in this case the scope should be “whatever is demanded by users, subject to veto by contributors”. The first part is simply because what is useful to Bitcoin Core users may vary so widely across usage types and time that it’s hard to draw a non-arbitrary line. The second part is to reflect that developers won’t implement features they believe to be harmful or dumb despite there being user demand (think colored coins, inscriptions, altcoin client, ..). Near infinite resources means we can assume only those users interested in a feature set bear its associated costs (larger binary, additional dependencies, etc). Of course it also means that implementing, reviewing and maintaining a new feature does not materially affect the ability of preserving the quality of the rest of the software.

Unfortunately in real life we do not have near infinite resources. Work on a new feature necessarily presents an opportunity cost: this development and review time could have been spent elsewhere. In addition it presents future costs: it will have to be maintained, and may interact with new features being introduced later on. Future work on test infratructure, modernizing the codebase, etc.. now will have to deal with it. This is not an abstract concern. It is also made worse by the incentives surrounding the contribution dynamic. Absent a project scope, any feature that receives enough review could make it in. The authors get the benefit of getting their feature merged into Bitcoin Core, and the maintainers and future contributors pay the associated costs.

These costs mean we need to make tradeoffs. We cannot both keep piling more code, more features AND also maintain a high bar for quality. High bar for quality meaning the code we ship received significant scrutiny, testing and that we are actively working to find bugs (especially security-critical ones). Does this mean we should allocate all our resources toward improving testing and review? Absolutely not! Some developments are well worth the risk and maintenance cost. And software costs/risks need to be balanced against network and industry wide costs, risks and opportunities. That is, a Bitcoin Core vs Bitcoin tradeoff. For instance it’s worth it for Bitcoin Core to bear the complexity introduced by package relay because it significantly improves the robustness of second layer protocols used by a large number of Bitcoin users. Another example is compact block relay. Does CVE-2024-35202 means Bitcoin Core should not have implemented this protocol upgrade? Absolutely not! Implementing mitigations against fundamental centralization pressures in Bitcoin literally is at the core of Bitcoin Core’s mission.

But what is Bitcoin Core’s mission? It seems obvious to say that block relay should be a priority for the Bitcoin Core project. But at what cost? And how do you generalize that? Here again, the answer is the vague truism “Bitcoin Core should prioritize in function of what its users value most”. But different users are going to value different things. Some will prefer to have new indexes to query mempool data, others will want a more efficient wallet that support higher loads, and others yet would prefer to have Assumeutxo implemented in the GUI. And from this it’s easy to shrug and conclude “there is no good way to prioritize one type of user over another, people will just work on what they want”. But this is sticking the head in the sand to avoid seeing the issue and this is missing a critical distinction in the group of Bitcoin Core users.

For technical and historical reasons, Bitcoin Core is the only reasonable full node implementation for all Bitcoin users to run. Re-implementations of Bitcoin face significant technical challenges and appear to be doomed to have consensus bugs. Forks of Bitcoin Core, while more reasonable to run from a consensus bugs perspective, have nowhere near the level of quality assurance Bitcoin Core has. But Bitcoin Core does not hold a monopoly, and its advantage can erode. A large share of users turning to other implementations would be a major setback for the project, and, given the state of available alternatives at the moment, one for the industry at large too.

When you consider that Bitcoin Core’s userbase is indirectly all Bitcoin users, how to prioritise development becomes quite clear. Bitcoin Core should be a robust backbone for the Bitcoin network, balancing between securing the Bitcoin Core software and implementing new features to strengthen and improve the Bitcoin network. I know this feels like stating the obvious, but sometimes it appears to be necessary.

Bitcoin Core project direction

Fri, 24 Jan 2025 00:00:00 +0000

What should be the mid to long term goals of the project?

This is something i’ve been thinking about and discussing with others for a while. I don’t quite have finished thoughts about this, but i think it’s important to discuss. It’s also a good time as most of us will meet in person soon.

A lot of decisions we make now about what features should go in, which should be prioritized, what to review, what is valuable to start working on, are dependent on what we expect to happen in the future. However, we currently cannot have any expectations about what will or will not happen in the future. This significantly hinders our ability to make progress.

I think we are in this situation where everybody is working on their own thing and there is no broad agreement about what the scope of the project should even be. As a consequence, year after year we keep piling up more code, more features, more RPCs, etc.. with at best a constant amount of competent reviewers’ time. This is not tenable, as a focus which gets further dispersed will inevitably lead to reduced overall software quality.

In addition there is a lot of wishful thinking. At a larger level, in the form “Bitcoin Core SHOULD definitely feature X” with no consideration whatsoever about the tradeoffs. At a smaller level, as we’ve seen with the priority projects degenerating into people voting about what others should spend their time on. And finally at a local pull-request level. Any contributor will know about these PRs that nobody NACKs although they aren’t going anywhere because people have looked into it and don’t think this is a good idea. But seldom would someone say it out loud as they’d bear the cost for everyone else, despite it being a net benefit with regard to project-wide resource allocation. We all wish someone else would do it for us, or that the author would magically lose interest and work on more important things. Or even that this SHOULD happen, oh, yes, definitely SHOULD happen, but others should carry the burden of review, maintenance and responsibility. Or its variant “oh yes i’ll help, absolutely, just not right now, maybe next decade”. Being enthusiastic to people’s idea is well-intentioned, and not saying no is the comfortable thing to do. Unfortunately it also has negative consequences, both direct and indirect. When making decisions about where to take the project we need to discuss “should” as bounded by “can” -and not “could”- or we’ll stay stuck in this untenable position.

At this point you may think this is not specific to Bitcoin Core, that it’s the fate of any open source project with no Benevolent Dictator, the Cathedral vs the Bazaar, all that. But it’s not because there is no hierarchy that we can’t be more efficient. That we can’t decide of a direction for the project. Finding broad agreement on a few guiding principles for what Bitcoin Core should be will help determine what should or should not happen at all. It’s also the basis to form rough consensus on concrete goals to set ourselves, which in turn can go a long way in prioritizing development.

Aligning ourselves on a set of specific goals for the project helps gather support for making uncomfortable decisions. For instance saying no to a feature someone invested time in developing, or getting rid of legacy components. But it also enables us to resolve the coordination issue in making things we decided should happen, actually happen. Compared to other open source projects in a similar situation we have the immense advantage of disposing of substantial financial resources. There are Bitcoin Core dev offices in New York, London, and soon, Amsterdam and San Francisco. For instance, those could be used for a sprint if we think something that should happen cannot because it did not get enough review from key contributors in this area. Setting clear goals would not only help us fight against scope creep, it would enable us to make better use of the means at our disposal.

We don’t need a benevolent dictator for this to happen. We just need sufficient buy-in from active contributors. This is up to us.

On Soft Forks

Wed, 18 Dec 2024 00:00:00 +0000

It appears many have different perspectives on soft forks than i do. Recent events and private discussions prompted me to share my thoughts on the topic.

Bitcoin’s value proposition is to be censorship-resistant money (some like to say “decentralised”). And so far it largely succeeded: 15 years after its inception it’s still possible for anyone with occasional access to the internet to receive, store and send value globally through the Bitcoin network without having to ask anyone for permission. This is remarkable, and it would be a great achievement if we can keep it this way for another 15 years. There seems however to be little demand for using Bitcoin (at least, as a medium of exchange). Or maybe just everybody is using Lightning and channel closures are a thing of the past. Some believe many would like to use Bitcoin but are simply unable to, and this seems to be one motivation behind the recent soft fork excitement. Another common, presumptuous, explanation is that actually a lot of people need Bitcoin, but they don’t realise it. It’s necessary for the western bitcoiner, well educated in the Bitcoin cult, to come and coinsplain them why they need to accept Bitcoin in their heart despite having already made the choice it was not the best option for them. We should note however that a low usage of Bitcoin can be viewed as a good thing: the contrary may imply large scale economic repression is happening.

Bitcoin achieves its goal of being censorship resistant money through coordination. Users coordinate around a fixed set of rules defining the money. These rules are embedded in software: a Bitcoin client (or node). One rule defines how clients coordinate to agree on the state of the system: transactions are ordered in a chain of PoW. Most realise how the censorship-resistant coordination permitted by mining is fundamental to Bitcoin. It is important to take a step back and also realise how amazing it is that millions across the world today coordinate around a fixed set of rules for their money. This happened progressively as Bitcoin grew, and it’s hard to see how it could be replicated today. We need to appreciate how fragile is this coordination of millions of people spread around the world, with different backgrounds, cultures, incentives, on something as political as the rules defining their money. Politically as much as technically, consensus is the most important feature of Bitcoin and we must be very careful in risking it.

A soft fork is an update to the consensus rules defining Bitcoin. It is technically a backward-compatible update, making it much safer to roll out on the network. However, it is still an update to the rules defining the money. The “soft” qualifier, while well deserved from a technical standpoint, had the unfortunate consequence of making it sound less politically dangerous to some. It is not.

In the past couple of years, a number of Bitcoin enthusiasts and developers published proposals to introduce new functionalities to the Bitcoin scripting system. A common complaint emerging from this group (both formulated publicly or reported to me in private discussions) was the lack of engagement of protocol developers, and especially of the fetishised Bitcoin Core maintainers, with their proposals. I have reasons to provide for the lack of engagement, but before that i want to address the Bitcoin Core attacks and criticims.

In a broader context, i believe much harm arises from attributing intentions to groups of people. Sure, people engage in groupthink. But at the end of the day each individual has his own interest, motives and responsibility. The same is true for the emergent group of developers happening to be contributing to the Bitcoin Core open source project. There is no loosely defined “Core devs” to blame. It is also important to realise how small the group of contributors is compared to the criticality of the project and the many areas it covers (cryptography, validation engine, mempool/mining, transaction and blocks propagation, nodes addresses management, indexes, wallet, GUI(s), build system(s), utilities, ..). Even smaller is the group of contributors actively working on “protocol stuff”. And it’s not like there is a shortage of important problems to tackle, despite what some may say.

Maintainers in particular take a lot of undeserved shit. Note they are also contributors working on their own projects: Ava on improving the wallet (such as to use the features enabled by the last soft fork, which we are still far from taking full advantage of), Gloria on package relay (to secure the second-layer protocol(s) enabled by the second-to-last soft fork), Michael on the toolchain (so Bitcoin survives one more release cycle without being backdoored a la xz), and Russ on multiprocess (to be more robust against situations like this). But when acting as maintainers, they are mainly directed by what other contributors are interested in working on. They coordinate and facilitate activitites of the various contributors and, to be honest, take care of a lot of things regular contributors are often less concerned with (broken CI, dependencies management, releases and backports, codesigning, spam on the repo, …).

Therefore maintainers’ activity largely reflects what the larger group of contributors is interested in. If you are mad at a maintainer for not engaging with your pet project, it only talks to your inability in getting any single of the Bitcoin Core contributors interested in your proposal.

With that out of the way, let’s now discuss the lack of interest in the recent proposals. I can only talk for myself, although others may agree with (parts of) the analysis. It is also worth to explicitly mention not all contributors are ignoring all proposals: some individuals who contribute to Bitcoin Core did engage with some proposals, or even came up with their own. I did take part in some of the discussions, albeit less so in the past year. Anthony Towns developed and maintains a whole implementation dedicated to testing proposals. Greg Sanders went through all the work of making an Eltoo proof of concept: design the scripts to be used, design the protocol as an extension of the existing BOLTs, actually implement it and start discussions (themselves backed by concrete proposals and implementations) about the necessary changes to the transaction relay protocol to make such channels more robust. This is so far the most extensive work i have seen supporting any of the existing proposals, but this is not something you will learn from listening to the full-time Twitter soft fork influencers.

A first reason for my lack of engagement is that there has been a lot of motivated reasoning of the kind “we need a soft fork; X is a possible option; let’s do X”. A common variant has “it’s been too long since the last soft fork” as its first step instead. This couldn’t be farther from my vision of Bitcoin. A soft fork is a risky, costly, mean to an end. We should not do a soft fork for the sake of doing a soft fork.

A related pattern i have noticed is what i dubbed the “irrational intervention”. It goes like this: “Bitcoin is imperfect; we must change Bitcoin; X is a possible option; let’s do X”. I think this is an emotional response to witnessing a suboptimal situation, and succumbing to this strong appeal to “do something about it”. There is also the “try something” variant which explicitly acknowledges the person has not rationally assessed whether X is at all a solution to the problem identified. It’s hard not to draw a parallel between this attitude and the block size debates from 10 years ago. We should not do a soft fork without a careful analysis of its costs and benefits.

This leads us to a third reason, probably the most common. It seems most proposals are a solution in search of a problem. Don’t get me wrong, these are often interesting to think about, and usually neatly tie into existing research and constructions. But until their champion(s) can make a strong case that they will bring tangible improvements to real-life Bitcoin users, they are not reasonable to consider for a soft fork. It is not true of all proposals, as some were designed to address a specific usecase. I have looked into some but none really convinced me they were worth changing Bitcoin’s consensus rules. And i say that despite having a strong financial interest (1, 2) in some of them making it in.

Another reason is that time is in fact scarce, and people’s imagination for Script opcodes unlimited. Nowadays everyone and their cat have a soft fork proposal. My recently joining Chaincode Labs was motivated in parts by having more time to keep up with the research in this area. Still, we all need a way to prioritize which proposals to give attention to, among other important works which also need our attention. I have to say the pretty low SNR of some discussions in the past couple of years led me to realise my time was better spent elsewhere. A mailing list is a 1-to-N mechanism. If someone is going to post to the mailing list, it’s reasonable to expect them to be familiar with previous research on the topic, to not be rehashing previous discussions without bringing anything new to the table, to be presenting their ideas to be understandable to a reader who does not have all the context and to not be sharing half-baked ideas that take longer to debunk than to broadcast.

I am excited by the prospects of all the energy invested in exploring the design space of extending Bitcoin’s scripting capabilities. If someone comes up with a way to make Bitcoin significantly more accessible or more robust, a soft fork should definitely be on the table. But the upsides must compensate for the costs of a soft fork. Bitcoin users is a much broader group than Bitcoin enthusiasts, let alone than Bitcoin Twitter. And coordinating on changing the rules of all of these people’s money is inherently political. There is nothing wrong with discussing soft forks, on the contrary. More research is better. But to be taken seriously, anyone suggesting to activate anything needs to acknowledge a soft fork comports substantial political and technical risks to a network that millions depend on for their censorship-resistant payments and that secures trillions of dollars worth of other people’s money.