Bitcoin hit hard by a DoS attack

Bitcoin is undergoing a DoS attack that is starting to become painful for nodes. Summary of the situation.

What’s the problem?

Without the 21M limit, there would be no reason for bitcoin to exist. The beauty of the system is that we are naturally incentivized to reject any attempts to modify this cap. The reason being that it would be like shooting ourselves in the foot by devaluing our own bitcoins.

However, bitcoin is not a monolith with a code that is completely set in stone. Bitcoin Core needs some tender loving care now and then. Sometimes, soft forks are proposed, not without controversy. The most recent ones were SegWit and Taproot.

The issue is that each alteration of the protocol brings its share of unexpected bugs. Ordinals are a perfect illustration of this. Those who are still unclear about it can read this article: Ordinals, enhancement or attack?

In summary, ordinals are arbitrary data masquerading as art. They are essentially jpeg/json files embedded within transaction scripts that bypass the limitations on the size of arbitrary data permitted.

These inscriptions also benefit from a reduced transaction fee. Data is indeed four times cheaper in the “witness” transaction segment introduced by SegWit, where ordinals are specifically inserted.

Bugs (Un)expected

Jaqen Hash’ghar had warned us about the risk of DoS attacks that SegWit would bring forth. He wrote in this article published in 2016:

“The theoretical 4 MB limit creates a major issue. […] There is a financial incentive for bad actors to design transactions incorporating heavy and complex data in the witness [ordinals…]. This problem is exacerbated by the fact that the scripts related to the witness (P2SH-P2WSH) can be larger than normal.”

The problem has since worsened. Bitcoin Magazine indeed wrote in 2021 about the Taproot soft fork:

“The 10,000-byte limit for scripts will be removed […]. The limit is also lifted for ‘opcodes’, which will allow more functionality that paves the way for smart contracts.”

In other words, certain developers have burst important levees to endow bitcoin with superfluous functionalities.

As a result, shitcoiners exploit these vulnerabilities by trying to turn bitcoin transactions into casino chips. The bigger the Ponzi scheme tied to these inscriptions, the more expensive legitimate transactions will become.

Not to mention that to the premature explosion of transaction fees, we must add the explosion of the cost of a node and the downloading time of the blockchain which today varies between 3 days and 3 weeks depending on the region…

Bitcoin centralization

Bitcoin has been around for 15 years, but its blockchain has grown from 446 GB to 537 GB in just one year (+20%). Between 2016 and 2023, it increased on average by 55 GB per year. In 2023, it was 93 GB, mainly due to ordinals.

Worse, over the same period, we observed on average 7.3 million additional UTXOs per year. In 2023, it was closer to 80 million.

Il a fallu 14 ans au #Bitcoin pour atteindre ~80 millions d'UTXOs et moins d'un an pour doubler ce chiffre.

🥶 pic.twitter.com/JjVu7xKERJ

— Nicolas Teterel #FixTheFilters (@NTeterel) January 29, 2024

The fault this time lies with the stamps protocol, which is part of the same attempt to graft a casino onto bitcoin transactions. The principle is that the jpegs masquerade as “bare multisig” keys.

Understanding why stamps is even more problematic than the ordinal protocol requires recalling that there are two types of nodes.

On one hand, there are “full nodes” that hold the entire blockchain. On the other hand, there are “pruned nodes,” which merely verify blocks before discarding them. These, however, must hold the entire UTXO set (a handful of GB).

But, the stamps protocol generates inscriptions that cannot be pruned since they are present in the UTXO set, not in the witness.

Here’s the result:

1 input.

1,001 outputs. pic.twitter.com/LjIinlkuCd

— Bitcoin Lebowski⚡ (@DudeJLebowski) January 28, 2024

The larger the UTXO set grows, the more RAM (Random-access memory) is needed, which is very expensive. This brings us back to the issue of network centralization.

It is probably the most blatant bug since the “infinite money” bug. Fixing it shouldn’t even be controversial.

The solution: Filter transactions

Before finding their way into a block, transactions are relayed between nodes on the P2P Bitcoin network, which cache them in their mempools. The exceptions are transactions inserted directly by a pool.

To mitigate some DoS attacks, Bitcoin Core nodes limit transactions that can be relayed. Transactions considered “standard” are relayed, while “non-standard” transactions are not.

Frequent non-standard transactions – which is the case with inscription-containing transactions – mean that “policy rules” (the filters) must be adapted to stop the DoS attack.

In the jargon, we talk of “policy check,” as opposed to “consensus check.” Consensus rules determine whether a block is valid. For instance, the one MB per block rule.

Consensus rules are verified by the nodes upon receiving a block propagated by the miners. In contrast, the “policy check” applies upstream, at the level of the mempool.

Many filters have appeared over time. For instance, the mempool considers invalid a transaction where the amount is less than it would cost to create and spend it (bitcoin dust limit).

The mempool also does not accept transactions weighing over 100,000 bytes or those paying less than 1 sat/byte in transaction fees.

In short, the solution proposed by Bitcoin Core developer Luke Dash is to extend the reach of the -datacarriersize filter. The goal is to limit the amount of data that can be included in transactions.

Bitcoin -Datacarriersize

-Datacarriersize refers to the amount of data in so-called “Op_Return” transactions. This type of UTXO was introduced to offer an alternative to more harmful techniques of inserting arbitrary data into the blockchain.

In 2014, doing anything not to clutter the blockchain was a given. So, it was decided to limit the amount of arbitrary data in standard transactions to 83 bytes. Essentially, enough to enter a simple hash.

Luke Dash jr even considers it a bug that -datacarriersize was not applied to all transaction data during the Segwit and Taproot soft forks. That’s why he developed the ordirespector patch available through the client Bitcoin Knot.

The stamps protocol can also be stopped by changing the default value of -permitbaremultisig to 0.

Many defeatists (corrupted?) would like us to believe that filters don’t work. Dishonestly, they assert that an “effective filter must prevent 100% of spam, forever.”

Reality is, the threat of systematically filtering inscriptions would be enough to discourage any attempt. If only Bitcoin Core developers had some guts. Hello Andrew Chow…

A small majority of nodes would be enough to block the propagation of these toxic transactions. Those orchestrating them would then have to resort to much more laborious means requiring direct partnership with pools.

We could then encourage miners to leave pools engaging in inscription trafficking with transaction fees paid under the table in complete opacity.

Collection of statements calling to curb inscriptions

Here’s a list of statements collected by glozow in favor of developer Luke Dash’s (and Ocean pool founder) proposal to extend -datacarriersize to all transaction data:

– “We must stop inscriptions, they are spam”

“Inserting data is an abuse of the taproot script.”

“The ability to embed arbitrary data is a ‘vulnerability.”

“If bitcoin is a currency (it is!)… then non-monetary transactions should be as much reduced as possible.”

“This is a misuse of the network. Bitcoin was meant for financial transactions (the white paper, its title, and the code indicate that)… Data storage was not a intended use case.”

– “Inscriptions are damaging the network”

“It causes network congestion and higher transaction fees or slower processing times. It is a DoS attack.”

“The issue is not with inscriptions, but with the astronomical transaction fees that result.”

“These transactions affect network decentralization by increasing the operational cost of running a node.”

– “Nodes want an option to filter inscriptions”

“Node operators need an option to ignore all modern forms of data insertion so they don’t have to manually patch their nodes.”

“I want to be responsible for the ‘policy check’ of my node’s mempool. I want to decide what is spam and what’s not.”

– “Just fix the -Datacarriersize so it works as intended”

“Bitcoin Core already prohibits arbitrary data insertion above 83 bytes (Op_Return). Inscriptions are a way to bypass this limit. So it’s a bug that needs fixing.”

“Spam is already filtered at various levels of the code, and has been for over a decade. We need to enforce an existing limit wherever there are vulnerabilities that allow for spam to be inserted into the blockchain.”

“What’s the goal of -datacarriersize limit (Op-Return) if not to impose a limit on arbitrary data?”

Collection of statements calling for passivity

Here are some arguments (sometimes in bad faith) by those who refuse to filter inscriptions:

– “It won’t stop the inscriptions”

“If only Ocean pool uses these filters, and remains a relatively small pool, it will have no effect. And even if these filters are widely deployed, it will be easy to bypass them.”

“It’s obvious that a block built from a filtered mempool will offer lower transaction fees than a block built from all transactions. This means that miners who filter inscriptions reduce their own income in favor of miners who do not filter.”

“It is highly unlikely that miners will give up this revenue stream. Censoring of these transactions would only encourage the development of private mempools.”

“Those conducting these inscriptions could maintain the relaying of inscriptions on the network by ensuring that a small fraction of nodes does not filter out the inscriptions.”

“Ordinal transactions will end up in the blockchain anyway, bypassing the mempool [by directly contacting pools], so these filters would do nothing to solve/mitigate the problem.”

– “We cannot write code to detect all arbitrary data”

“There is no universal way to filter all current and future styles of arbitrary data insertion. This invites an endless game of cat and mouse […].”

“Trying to prevent all types of data insertion will result in code complexity. And each time this happens, there will be strong pressure on Bitcoin Core maintainers to push it through quickly to stop the spam.”

“As far as I can tell, there is no reasonable way to prevent people from storing arbitrary data in the witness without encouraging even worse behavior [stamps] and/or breaking legitimate use cases.”

“-Freeee market”

“It’s not up to us to tell people how to use bitcoin.”

“Bitcoin is a permissionless decentralized network… anyone can use their bitcoin however they wish, even if the use case is unpleasant (for whatever reason).”

Bitcoin is suffering a highly sophisticated DoS attack. It’s about time it is addressed before ordinals, BRC-20, SRC-20, and other ersatz shitcoins take over.