Bitcoin Core Developers Under Fire

Ordinals and other « inscriptions » continue to cause unrest. Accusations of collusion abound against certain Bitcoin Core’s developers.

Bitcoin Core

Several developers in charge of the client Bitcoin Core are being heckled for their passivity towards so called « inscriptions » such as ordinals and other arbitrary data used to build scammy ponzis like the ORDI shitcoin.

Bitcoin Core is an implementation of the Bitcoin protocol. It is the direct descendant of Satoshi Nakamoto’s work. It is both a node and a wallet. Its code is maintained by hundreds of contributors.

This is not the only available client (there are more, like the Bitcoin Knots client, not as spam friendly as Core).

Code evolutions are proposed via Pull Requests. Most are minor, but some can be major and these are often accompanied by BIPs (Bitcoin Improvement Proposals) that can sometimes lead to soft forks.

A handful of developers known as “maintainers” have the power to authorize (« merge ») code modifications. This small conclave has the final say on the Bitcoin Core implementation, which represents 98% of all nodes.

Since the recent departure of the veteran Van der Laan, the five maintainers are Michael Ford, Andrew Chow, Russ Yanofsky, Gloria Zhao and Hennadii Stepanov.

However, here’s the ranking of contributors ranked by the number of BIPs they spearheaded :

Luke Dash – the second largest contributor – sparked a controversy by inviting Bitcoin Core to act to stop Inscriptions and other wasteful transactions from attacking the network.

Arbitrary data non grata

Luke Dash did so through a Pull Request on the 5th of January 2023 : “Witness scripts being abused to bypass datacarriersize limit”.

Here is the description of the Pull Request :

“The datacarriersize policy option is meant to limit the size of extra data allowed in transactions for relaying and mining. Since the end of 2022, however, attackers have found a way to bypass this limit by obfuscating their spam inside OP_FALSE OP_IF patterns instead of using the standardized OP_RETURN. This remains under active exploitation to a degree very harmful to Bitcoin even today.“

Explanation :

In Luke’s PR, Datacarriersize refers to the “OP_RETURN” opcode. It was created in 2014 to offer an alternative to the more harmful techniques used at the time to insert arbitrary data on chain. It offers a limited space of few dozens of bytes per transaction. That’s enough to enter a SHA-256 hash (32 bytes) as well as an identification tag.

Luke Dash considers it a bug that Datacarriersize was not applied to all types of transaction data in the Segwit and Taproot updates.

Fingers are often pointed at SegWit and Taproot because of the increase and then elimination of the maximum size of transaction scripts. But that’s a bit of a leap. For Luke Dash :

« The maximum size of transaction scripts was not lifted for purposes of exploiting it for data injection. Data injection could always exceed the limit at the consensus level. If the script was too big, it would simply not be executed. Spam filters have always been at the policy level, and that’s where they ideally belong. »

In the absence of filters, arbitrary data can easily be injected by anyone for any purpose through transactions that would have otherwise been rejected by default mempool policies. This attack vector has been exploited by BRC-20 and Inscriptions to circumvent the Bitcoin protocol limitations and subvert its purpose.

Filters (policy rules) hinder transactions undesirable by noderunners from being relayed by nodes into a block. For example, Bitcoin Core does not relay transactions weighing more than 100,000 vbytes, or those paying less than 1 sat/vbyte in transaction fees.

This is enforced by policy rules, aka « filters ». And yes, you have been running these filters if you’ve been running the Bitcoin Core client with default settings.

In short, filters would allow to fight against this whole DoS operation being payed for by those who are lurred into buying scammy inscriptions. It is a sophisticated attack which is sort of self sufficient in terms of budget.

This can be considered “very harmful” because these hundreds of thousands of voluminous inscriptions lengthen the initial synchronization time of a node, which already takes between 2 days and 3 weeks. Not to mention the premature rise in transaction fees and the growing memory required to run a node.

Fixing a bug through documentation change…

Bitcoin needs a large number of nodes to be decentralized. It is therefore vital to contain the growth of the blockchain and the UTXO set as much as possible. A blockchain cannot be a parking lot for jpegs and transactions should not be turned into casino chips.

Op_Return bears witness to a time when any misuse of Bitcoin transactions that weighed on nodes was considered an attack.

Unfortunately, the new and inexperienced Bitcoin Core’s maintainers refused to send a strong message by updating the filters. Andrew Chow, Gloria Zhao and Marco Falke have been heavily criticized since noderunner Unhosted Marcellus discovered a stealth modification to Bitcoin Core’s documentation.

Marcellus realized that maintainer Marco Falke rewrote the documentation about Datacarriersize just after the Inscription craze began. The definition was changed from:

« Maximum size of data in data carrier transactions we relay and mine. »

to

« Relay and mine transactions whose data-carrying raw scriptPubKey is of this size or less : 80 bytes. »

Then maintainers Gloria Zhao and Ava Chow used that new meaning of datacarriersize as an argument to reject the fix…

It is AJ Towns and Gibbs who gave their greenlight (ACKed) to the redefinition. Then @fanquake merged it :

For non-technical plebs: Bitcoin Core v26 vandalized the description -datacarriersize so that it leaves out the spam, instead of fixing the bug.@MarcoFalke made the change, @ajtowns and @theinstagibbs gave their ACKS.@fanquake merged it. @achow101 defends the change. https://t.co/c663VC2DOB

— Unhosted Marcellus 🚫👻 (@oomahq) January 3, 2024

In other words, it was realized quite early on that the Bitcoin Core code did not behave according to the description in the documentation. But instead of fixing the code, maintainers chose to change the documentation… After the discovery of this anomalous change by the plebs, maintainer Achow made the claim that adapting the documentation was somehow a way of eliminating the bug…

Several noderunners have accused maintainers of insidiously reducing the scope of Datacarriersize to justify inaction on new techniques of data injection into transactions.

Overall, this contortionism aimed at protecting the inscriptions’ circus is worrying. Faced with this Commedia dell’arte, Luke Dash has taken the lead by developing the “ordirespector” patch.

Ordisrespector is a spam filter that does not relay transactions containing ordinals. Head to the Install page to learn more about running this patch or even running an alternative Bitcoin Core client, Bitcoin Knots, that does not relay scammy/spammy transactions.

If you are a miner, you can filter your mempool by pointing your hash to Ocean Pool.