Bitcoin Core Devs under fire of criticism

A disturbing change of philosophy is at work in Bitcoin Core developers.

No_return

Bitcoin Core is again under the fire of criticism. The French developer Antoine Poinsot threw a pavement in the pond by proposing to remove the limit on the quantity of arbitrary data (spam) which can be inserted “legally” in transactions.

Here is in essence its proposal (truncated version) which he details more in length on his blog ::

By default, Bitcoin Core propagates and only undermines the transactions containing as much as possible an OP_return that does not exceed 83 bytes. […] However, some manage to get around this limit. I therefore propose to delete it to stop encouraging more harmful data insertion techniques […].

Antoine Poinsot

Let's start by explaining what is ” Op_return ». It is an OPCODE to properly insert arbitrary data into a transaction. This “official” method offers a limited space of 83 bytes to do this.

Transactions using OPCODE OP_PRETURN have this particular that they generate UTXOs can no longer be spent (Unspendable Output). Use op_return is used to report to the nodes that they do not need to memorize the UTXO of the transaction in question.

[On appelle UTxO les petits bouts de code (les « scripts ») qui lient mathématiquement les bitcoins à des adresses BTC (les adresses étant des encodages de clés publiques).]

The vase overflowed when the developer Peter Todd proposed to completely delete the possibility that nodes have to configure the OP_return limit themselves:

Also remove the configuration option -Datacarriersize […]. This limit is in any case easily bypassed via direct submissions to the mempools of minors (for example, Mara Slipstream) or certain insertion techniques.

Peter Todd

We will explain everything, don't panic.

Data Non Grata

What are we talking about exactly? What are these “arbitrary data” that cause so much ink to flow?

We commonly speak of “inscriptions”. The best known are the “ordinals”. These are generally JPEG images that squat inside transactions (P2TR). There are also the Stamps, even more harmful. These store data in the form of public keys and generate huge quantities of UTXO (Baremultisig).

These inscriptions all have in common to bypass OP_return in order to escape its limits, which is not without consequences. While the UTXO SET weighed only 4 GB before the fashion of inscriptions, we are today at 12 GB. Half of the UTXO contain less than 1000 SATS, that is to say spam.

This growth threatens decentralization since it becomes more expensive to install a node (memory, RAM, IBD, etc.). Another drawback is to encroach on the legitimate use of the network, namely making monetary transactions.

Now clarifions the expression -Datacarriersize. This is the name of the configuration parameter defining the limit of Op_return. By default, this limit is set at 83 bytes in the recent versions of Bitcoin Core.

Peter Todd here affects what are called “policy rules”. These rules make it possible to filter transactions to prevent their spread to the mempools of minors in order to be added in a block. The goal is to prevent certain attacks by denial of service (back). For example, Bitcoin Core does not propagate transactions weighing more than 100,000 voctets.

[Le mempool (contraction de memory pool) contient les transactions valides en attente d’être incluses dans un bloc. Chaque nœud à son propre mempool et ses propres configurations de filtre.]

Now that the bases are laid, let's get to the heart of the matter. It has been two years since the developer Luke Dashjr advises to filter transactions containing inscriptions.

Problem, the small conclave of developers at the head of Bitcoin Core refuses to do so.

Know how to limit breakage

Bitcoin Core justified his passivity by advancing that filters going against the financial interests of minors will end up being bypassed. This is also done with the “Slipstream” system of the minor marathon.

Slipstream allows you to bypass the nodes of the network by sending the transactions (which would be otherwise filtered) directly in the marathon mempool.

Certainly, but this service is not free. The more the registrations will be expensive to produce, the less there will be. Everything is good to take to limit the breakage. Not to mention the fact that Marathon undermines less than 5 % of the blocks.

It is very simple, only 30 OP_Turn transactions out of 7 million have exceeded the limit of 83 bytes since the beginning of the year. This represents a success rate of 99.9957 % for the anti-spam filter limited to 83 bytes.

Let's go back to Peter Todd now. Her proposal disturbs since she looks like a capitulation against the spam industry. Especially since lifting the limits of Op_return most likely will have no positive impact regarding spam.

For what ? For the right and simple reason that the new insertion techniques are four times cheaper than with OP_Preturn because they take advantage of the “Witness”.

This huge rebate is linked to the soft fork segwit which brought the size of the blocks from 1 MB to 1 VMO. The “V” means “virtual”.

Segwit, at the origin of evil

Segwit is the fruit of a compromise from the “Blocksize War”, an episode which is worth explored. To be clear, Segwit made it possible to increase the size of the blocks from 1 MB to 4 MB.

This is due to the fact that segwit transactions are divided into two different sections. The bytes of the first section are counted as weighing 4 voctets, while the bytes of the Witness section weigh a single voctet.

Thus, a block containing 1 MB of conventional transactions (without segwit) weighs 4 VMO. A block of 4 MB containing a single transaction carrying an image of 4 MB in the Witness weighs 4 VMO.

The problem is that no one could predict (to tell the truth, if …) that the Witness would be exploited by spammers. The creators of Segwit thought that the Witness section would only contain legitimate ECDSA signatures and that the blocks would reach a maximum of 1.5 to 2 MB.

Today, the majority of spam is housed in the Witness of P2TR transactions. These scripts are not intended to be executed: they only serve as storage for arbitrary data (images, texts, json, etc.), up to 4 MB per block.

Who benefits from the crime?

The beginning of the answer may be due to the fact that the filters slow down the propagation of the blocks containing OP_return exceeding the limit of the 83 bytes. The minor marathon therefore has a financial interest in what this limit is removed.

The Citrea project by Jameson LOPP would also benefit from this. The Cypherpunk was also among the first to support Peter Todd's proposal. In this regard, note that Bitcoin Mechanic (CTO of the Pool Ocean) was banished from the Github Bitcoin for having stressed this conflict of interest. Ironic censorship …

Let us end by hammering that Bitcoin is a payment system. Facilitating other uses harmful to the decentralization of the network is a difficult pill to swallow. Faced with the deaf dialogue which settled with Bitcoin Core, more and more people migrate to other implementations such as Bitcoin Knots.

Bitcoin Knots is a modified version of Bitcoin Core maintained by Luke Dashjr. It is an alternative customer for the Bitcoin network. It offers additional features and bug corrections that Core developers refuse to do.

The next step is to cut food to organizations like @opensats, @bitcoinbrink, @HRF, as well as to remove its funds from ETFs that sponsor dictators. Hopefully the controversy will be enough to convince Bitcoin Core to do nothing.

Here for English speakers a long tirade from Bitcoin Mechanic to fully understand where we are:

If you are still there, you will certainly appreciate this article on Bitcoin and quantum threat.