Bitcoin Core Under Fire – Cointribune

A Troubling Shift in Philosophy Seems Underway in Bitcoin Core — Turning a Deaf Ear to Public Outcry, Ignoring Rough Consensus.

No return

Bitcoin Core is once again under fire, this time sparked by French developer Antoine Poinsot’s proposal to remove the existing limit on how much arbitrary (or potentially spammy) data can be “legally” embedded in transactions.

Here is, in essence, his (abridged) proposal, which he explains in more detail on his blog:

By default, Bitcoin Core only relays and mines transactions containing at most one OP_RETURN not exceeding 83 bytes. […] However, some manage to bypass this limit. I therefore propose removing it to discourage more harmful data insertion techniques […].

Let’s first explain what “OP_RETURN” is. It is an opcode that allows clean insertion of arbitrary data into a transaction. This “official” method offers a limited space of 83 bytes for doing so.

Transactions using the OP_RETURN opcode are special in that they generate UTxO that can no longer be spent (unspendable outputs). Using OP_RETURN in a transaction tells nodes they don’t need to store the resulting UtxO, hence saving space.

[UTxOs are the little pieces of code (“scripts”) that mathematically tie bitcoins to BTC addresses (addresses being encodings of public keys).]

The last straw came with a proposal from developer Peter Todd to outright remove the ability for nodes to configure the OP_RETURN limit themselves. Here is his (abridged) proposal :

Let’s also remove the -datacarriersize config option […]. This limit is easily bypassed anyway via direct mempool submissions to miners (e.g., MARA Slipstream) or certain insertion techniques.

We’ll explain everything—don’t panic.

Data non grata

What exactly are we talking about here? What are these “arbitrary data” that are stirring so much controversy?

The best known are “ordinals”. These are usually JPEG images embedded inside transaction scripts. There are also the more damaging STAMPS. Those ones store arbitrary data directly as fake bitcoin addresses. That means these STAMPS UTxO are unspendable and bloat the UTxO set forever.

What they all have in common is bypassing OP_RETURN to avoid its limits. And while it took from 2009 to 2023 to get to a 4GB UTXO set, we are now at 12 GB because of all this spam. Today, half of the UTxO are less than 1000 sats, meaning they are all useless spam.

This growth threatens decentralization because it becomes more expensive to run a node (disk, RAM). Another downside is that it encroaches on the legitimate use of the network : sending monetary transactions.

Let’s now clarify the expression -datacarriersize. It refers to the configuration parameter that defines the OP_RETURN limit. By default, this limit is set to 83 bytes since v0.9, released in March 2014.

Peter Todd is touching here on what are known as “policy rules.” These rules filter transactions to prevent them from being relayed to miners’ mempools for inclusion in a block. The goal is to prevent denial-of-service (DoS) attacks. For example, Bitcoin Core does not relay transactions larger than 100,000 virtual bytes.

[The mempool (short for memory pool) contains valid transactions waiting to be included in a block.]

Now that the basics are clear, let’s get to the heart of the matter. For two years now, developer Luke Dashjr has been calling for filtering transactions containing inscriptions.

The problem is that the small conclave of developers leading Bitcoin Core refuses to do so.

Damage Control

Bitcoin Core has justified its inaction by arguing that filters running counter to miners’ financial interests will eventually be bypassed. And indeed, that’s already happening via Marathon’s “Slipstream” system.

Slipstream lets one bypass the network’s nodes by sending transactions (that would otherwise be filtered) directly into Marathon’s mempool for inclusion in a block. This allows the creation of OP_RETURN transactions exceeding the 83-byte limit.

Sure, but this service isn’t free. The more expensive inscriptions are, the fewer there will be. Any disincentive helps limit the damage. Not to mention that Marathon mines less than 5% of blocks.

This year, only 30 out of 7 million OP_RETURN transactions exceeded the 83-byte limit. That’s 0.004246903% of the total. This represents a 99.995753097% success rate for the 83-byte anti-spam filter !

Let’s now return to Peter Todd. His proposal is disturbing because it feels like a capitulation to the spam industry. Especially since lifting OP_RETURN limits likely won’t even help.

Why not? For the simple reason that new insertion techniques are four times cheaper than OP_RETURN by using the “witness discount”.

This huge discount comes from the SegWit update, which increased block size from 1 MB to 1 virtual MB (vMB). The “v” stands for “virtual.”

SegWit, the root cause

SegWit is the result of a compromise made during the Blocksize War that it’s probably worth delving into. To be clear, SegWit raised the blocksize from 1MB to 4MB. But the consensus rule is not defined as “max 4MB” but “max 4 MWU (mega Weight Units)”.

Said otherwise, transaction are divided into two slots for SegWit transactions. Bytes of one section are defined as “weighting” 4 WU each while bytes from the witness section are defined as weighting 1 WU.

This makes everything balance out. A 1MB block full of legacy transactions (without any SegWit data) “weights” 4MWU. A 4MB block with a single transaction carrying a 4MB pic is also 4MWU, but pre-SegWit nodes never receive that data (they receive and see a mostly empty block).

The thing is that nobody could have predicted (some people actually warned against this scenario) that the discount given to SegWit data would be abused by spammers. When the witness data is only used for legit ECDSA signatures the blocks can only grow to about 1.5 to 2MB.

Today, most of the spam is inserted into the witness of SegWit P2TR-type transaction scripts. The script isn’t meant to be executed and only serves as storage for arbitrary data (images, text, JSON, etc.).

Cui Bono?

One possible clue lies in the fact that filters slow down the propagation of blocks containing OP_RETURN data beyond the 83-byte limit. It’s not crazy to think that an entity like Marathon pushed to have this limit removed.

Jameson Lopp’s Citrea project would also benefit from the removal of the 83-byte limit. The cypherpunk was among the first to support Peter Todd’s proposal. Notably, Bitcoin Mechanic (CTO of the Ocean mining pool) was banned from Bitcoin’s GitHub for highlighting this conflict of interest. Is Bitcoin Core becoming the monster it swore to fight — censorship ?

Another reason for removing the configuration option is to enhance « mempool homogeneity »: all nodes running the same mempool. That being said, Core devs can only have mempool homogeneity if Core is the only game in town.

Let’s conclude by reiterating that Bitcoin is a payment system. Legitimizing other uses harmful for its decentralization is concerning for many people.

The root of the conflict is that Core developers consider that mempool policy is their private property (you can clearly feel this in Poinsot’s blog post). If this disdain continues, the only solution is to abandon Bitcoin Core for other implementations like Knots.

Bitcoin Knots is a modified version of Bitcoin Core maintained by Luke Dashjr. It serves as an alternative client software for the Bitcoin network, offering additional features and bugfixes that Core devs refuse to deliver.

The next step is to cut off support for organizations like @OpenSats, @bitcoinbrink, and @HRF, and to withdraw funds from ETFs that bankroll developers who dismiss the voices of the plebs.

Let’s hope the controversy is enough to convince Bitcoin Core developers to do nothing. Rough Consensus should be cherished in open source development.

Here is a long tirade from Bitcoin Mechanic that gives a full picture of where we are today.

If you are still here, you might enjoy this article about the quantum threat to Bitcoin.

Nicolas T.

Bitcoin, geopolitical, economic and energy journalist.