Stats about non payment transactions

mempool.space's transactions by fee rate since 2020

mempool.space's transactions by fee rate since 2020

A clear increase in transactions entering mempool.space can be seen starting February 2023. Until today, such increases are usually only experienced by the network during the so-called "bull runs", making this one a noticeable anomaly. mempool.space

This mempool does not contain this kind of spam:

  • "inscriptions"
  • (fake) bare multisig
  • (fake) bare pubkey
  • OP_RETURN

space occupied by non-payments VS payments on the timechain since January 2023

Soon after the beginning of the 2023 spam wave, non-financial transactions have been occupying about 50% of the available blockspace, except during short breaks. This chart does not consider data storage transactions that use bare multisig. BTC spam analysis

fees paid by by non-payments VS payments on the timechain since January 2023

Although non-payment related transactions occupy about 50% of each block, the majority of the fees paid in each block are still coming from payments. This data shows how non-payment transactions (spam) are displacing payment transactions, this is forcing non-payment transactions to pay a much higher fee to be included in blocks. BTC spam analysis

size of UTXO since January 2023

Evolution of UTXO set size

The size of the UTXO set, number of unspent UTXO outputs, has seen a drastic increase since the beginning of the 2023 spam wave. This is partially due to Inscriptions/BRC-20 but mainly due to spam that relies on bare-multisig data to store data on the timechain. UTXO set size

Examples of spam in Bitcoin

There are the examples of the spam in Bitcoin:

"inscription without any input or output"

"inscription with input and output"

"spam with OP_RETURN method"

Characteristics of spam

During waves of spam, spam is always defended by spam supporters/defenders by claiming that spam is subjective and that what is spam for you might not be spam for someone else, as they might have a use for it. This section aims at addressing this mischaracterization.

Spam opponents often tend to define or characterize spam by defining it based on the purpose of the network (Peer-to-peer Electronic Cash system), although there is truth in this characterization, it is an argument that can be hard to defend as the purpose of the network is a concept that can be seen as subjective. However, spam can also be recognized by anyone, even intellectually honest spammers, thanks to two main characteristics:

  1. Wastefulness of the shared network resources
  2. Obvious misuse of Bitcoin's functions for a malicious purpose
    In addition, these transactions are also often sent in large volumes.

Transactions with no practical value or purpose, such as those submitted by supporters of big blocks during the Blocksize wars for example, are characterized by wastefulness as their output was too small to spend. Other examples of wastefulness are transactions that are sent back and forth repeatedly to the same addresses, transactions which carry no state information, transactions purposelessly split into hundreds of tiny outputs that are then recombined in the next transaction, etc... These transactions are malicious partly because they are wasteful, creating a backlog in the mempool that drives up transaction costs unnecessarily. The 2023 wave of spam is especially egregious because it involves storing obscenely large and unoptimized state data using methods that abuse several of Bitcoin's functions, such as the segregated witness script discount, OP_IF OP_FALSE codes, and bare multi-signatures.

"(...) There's a reasonable argument that this sort of data is toxic to the network, since even though "the market is willing to bear" the price of scares blockspace, if people were storing NFTs and other crap on the chain, then the Bitcoin fee market would become entangled with random pump&dump markets, undermining legitimate use cases and potentially preventing new technology like LN from gaining a strong foothold. (...)" - Andrew Poelstra, 2023 January 27, Bitcoin-dev mailing list

These transactions can be classified as spam due to their ignorance or malice, they could also occur off-chain relatively easily through NFTs with reference hashes or BRC-20 tokens with reference hashes much more efficiently and this was already proposed several times. Functionally, the result would be the same as it would allow users of this "standard" to verify the data without overwhelming the chain. BRC-20 tokens are not optimized at all for example and use clear JSON (!) instead of HEX or base64 encoding, demonstrating a complete disregard for the shared resource of the timechain. This failure is particularly concerning since they account for more than 50% of the average block's size, as shown in the BTC spam analysis blocksize graph despite being avoidable with a more responsible usage.

"(...) people really don't like this [NFT, Ordinals] and I apologize because they are kind of my fault that all that script limit relaxation I was talking about for TapRoot - that's why we can do it. (...) relaxing this script limits (...) makes one particular form of data stuffing possible." - Andrew Poelstra, 2023 August 28 , Stephan Livera Podcast episode 507.

The two characteristics presented above are a simple way to recognize spam that most likely violates the purpose of the network and the desired behavior, and Bitcoin actually supports other protocols that submit non-payment transactions which are not considered as spam by most participants. A good example is the OpentimeStamps protocol (there are also many bad examples), which uses Bitcoin for blockchain timestamping and is not considered as spam by most participants in the network as it generally does not present the two characteristics presented above: it uses shared resources efficiently and does not misuse Bitcoin's functions.

Common narratives around spam

Mempool policy is censorship

First of all, it's important to understand that each node runs there own sovereign mempool, there is no such thing as a single mempool, although we often refer to the mempool.
The statement "mempool policy is censorship" implies that any policy applied to your mempool, which temporarily stores unconfirmed transactions in your Bitcoin node before they're added to blocks, is a form of censorship. However, this argument is wrong because mempool and relay are not forced on you by anyone and are not enforced over the whole network under threat; instead, they only allow you to take control over your own mempool and relay policies to prioritize or refuse to store or relay certain types of transactions. This is the opposite of censorship, this is what sovereignty means. This set of rules can be defined through your bitcoin.conf file to describe what a valid transaction is from the point of view of your own mempool.

Policy is everything that is not consensus. Modifying your mempool and relay policies does not go against consensus as you're only affecting what happens before transactions are included in a block. Your node will still receive, record and relay all blocks that are mined by the network and your node will remain within consensus.

Mempool policies are necessary for ensuring efficient and effective usage of the limited resources in the Bitcoin network during periods of high traffic or congestion while also prioritizing critical transaction needs like payments. Nodes are responsible for enforcing their belief of the purpose of the network, these policies are your voice on the network.

Censorship is defined as the suppression of speech, public communication, or other information, and is enforced by a central authority that will rely on violence or punishment to force everyone to delete and suppress said information. In the case of mempool and relay policies, since each actor is free to set their own rules without being forced to apply a specific set of rules (default rules are often kept by most users but that is a different subject), it is thus obvious that these policies are the opposite of censorship.

In the case of spam, refusing to store or relay it with your node can be defined as resource management or moderation, not censorship. Refusing to relay information that is not aligned with that purpose is a form of moderation, the same way an academic journal about physics will refuse a publication submitted about psychology. Publishing it would otherwise inconvenience most of the readers of that journal who are subscribing and reading that journal because they are interested in advancements in physics. The main difference in the case of Bitcoin is that the moderation and its enforcement is decentralized over all nodes through mempool and relay policies.
In addition, other users are not entitled to your node's resources. If you choose to not store or relay some transactions with your node, that is well within your property rights.

Running a node is an active process. You might have been told that if "you're running a node, you're good", that is just the first step. Noderunners must remain ever vigilant and ready to act in case of attack. This is effectively what makes Bitcoin anti-fragile.

A valid transaction is a valid transaction

Spam defenders will often point to the fact that a spam transaction is valid, in the eyes of the protocol, because it pays the required fee and respects the structure required by the protocol. Even though the transactor paid a fee, it does not mean that the transaction cannot be a spam transaction. By definition, spam will always be a valid transaction, it would otherwise not be relayed through mempools and won't be included in a block. That does not mean that some valid transactions are not violating the two definitions previously defined, meaning that the transaction can still waste the shared resources of the network and/or abuse one of Bitcoin's functions for a malicious intent.

Discussing the validity of the transaction is not the issue and participants should not let the debate diverge in that direction. Spam will always be valid, the questions that should be discussed are:

  • Are these transactions willingly wasting the shared resources of the network?
  • Is there a malicious intent behind this wave of transactions?
  • Can the purpose of these transactions be achieved more efficiently?
  • Are these transactions abusing some of Bitcoin's functions to circumvent limitations put in place to preserve the network's resources?

Another important detail is that some of the spam from the current wave, mostly inscription-based spam, can be considered to not be paying a fair fee as it circumvents the fair fee market by injecting data into the segregated witness space in order to benefit from a x0.25 discount. This is not the case for bare multisig based spam or OP_RETURN based spam.

The fees were going to be high anyways

Because Bitcoiners strongly believe that Bitcoin will be adopted by more users who see a need for Bitcoin's properties (citizens experiencing significant currency debasement, institutional users who require fast finality, users trying to circumvent capital controls, ...) combined with the choice to maintain a limited blocksize, there is a strong belief that transaction fees will become prohibitive in the future, excluding small users from ever using on-chain transactions. The hope is that Layer 2 solutions will be ready by then.

A common argument presented about the fact that spam induces high fees is that we all knew that high fees were always going to be high, so high fees shouldn't be an issue. This is argument is flawed for two reasons:

  1. High fees are not the issue when it comes to spam, the issue is about the wastefulness and abuse of the network's functions that cause harm to the network as a whole.
  2. The reason why fees are high is obviously important. The argument that fees were always going to be high assumes that there will be a strong demand for Bitcoin's properties. When spam is the reason why there are high fees on the network, that is obviously not the case. The high fees are not what matters, it's the adoption and demand for Bitcoin's properties that causes them that's important.

This second point can easily be understood with a simple thought experiment:

  • Let's assume that a nation-state level attacker funds an attack where they fill blocks with transactions sent back to themselves, consistently paying fees high enough to ensure that their transactions will be in the next block and stopping anyone else from transacting.
  • In this case, the fees will necessarily become high, but this situation will stop anyone else from transacting, stopping any real demand for Bitcoin's properties. The fees are high, yes, but would you still support a mitigation scheme to limit the reach of such an attack?

Satoshi inscribed on-chain so I should be able to do it too

A common argument presented by inscription supporters is that Satoshi started the trends of injecting data in the timechain with the Genesis block message. This argument is simply wrong since Satoshi did not subvert (2nd characteristic of spam) the protocol to "inscribe" data, they simply used space already available in the Coinbase data that is designed to allow miners to broadcast arbitrary data when a block is found. It's always been part of Bitcoin and didn't introduce any wastefulness.
More information here.

Mechanism used to inscribe the Genesis block message by Satoshi

In addition, this argument does not really matter as Satoshi's initial actions should not be blindly followed and used to justify your actions. Everybody can make mistakes, and no one can plan for all future scenarios, especially in a complex system such as Bitcoin that is highly unpredictable.

This event, instead of being taken as a justification that Bitcoin should be used as a perpetual highly-replicated database, should be considered as a celebration of the right ways you can post data on chain in a responsible way as it uses an existing method to store arbitrary data by miners that doesn't obviously circumvent a Bitcoin function.
Another way for Satoshi to publish his message would have been to use the OP_RETURN code as it would signal to the network that the data included in the OP_RETURN can safely be discarded outside of the UTXO set. Participants have been and are using OP_RETURN codes today to store short messages on the timechain and these are not considered as spam. If you're curious, you can explore these messages on opreturnbot.com. Learn more from the Bitcoin Explained Podcast.
It's still important to highlight that when the OP_RETURN code was released, it was clearly specified that "Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.". Another extremely important point is that OP_RETURN data is still stored on nodes forever, that is the reason why they are limited at 80 bytes, but OP_RETURN data does not benefit from the segregated witness discount.
Inscriptions that are omni-present in the 2023 wave of spam basically have the same impact on the network as OP_RETURN data except that they benefit from the segregated witness discount and manage to go above the 80 bytes limit using the OP_IF OP_FALSE injection scheme.

What's next?

  • Want to take control over your mempool's policies? You can easily do that by modifying your bitcoin.conf file. You can use the following tool, provided by Jameson Lopp to easily create a bitcoin.conf file that applies the mempool and relay policies you'd like to apply to your node.
  • More information about mempool policy and its role

Bitcoin can thrive even if miners are high-time preference greedy actors

The popular notion that miners must be inherently selfish and solely driven by profit has become a pervasive narrative within the Bitcoin community. The origin of this mostly false narrative is unknown and unclear. Originally, the Bitcoin whitepaper only mentioned the term "greed" once, and that is in the case of an attacker. This belief is not necessarily grounded in reality or based on sound reasoning. In fact, it overlooks two crucial points:

  1. Firstly, that miners need Bitcoin to remain valuable and profitable over the long term in order to recoup their investments and to have profitable businesses;
  2. Secondly, what makes Bitcoin valuable is that it's an electronic cash system with unique and distinctive properties, which can be undermined by excessive spam.

Because of the two previous points, it is evident that miners must be aligned with the long-term success of the Bitcoin network. In a sense, this does not mean that miners cannot run on high-time preference greed only, but that miners must care about low-time preference greed as well as high-time greed, and play a role in the network that balances the two. This directly contradicts the narrative that the system must run with high-time preference only greedy miners.

Spam being by definition wasteful and often serving malicious intents not only affects the efficiency of the Bitcoin system, which is already quite limited due to the blocksize, in addition to affecting its main usage as an electronic cash, which is where it derives its value from. If spam starts dominating the content of blocks, which is currently the case as of December 2023, it will displace monetary transactions outside of the network and degrade its value as an electronic cash. This is already case as can be seen from the increase in transaction volume on the Liquid network or the volume increase of the Canadian Purpose ETF BTCC, which directly affects the usage from which Bitcoin derives its long term value.

Bob Burnett discussed this in a Meme Factory podcast and explained this position from the point of view of a miner:

So, like, I find it funny, some people have been critical saying, well, you know, if you're a miner and you're mining with Ocean and you're not getting every fricking sat in every single block that you're doing a disservice to your investors or your owners or you're not maximizing economic advantage.
But if, let's say, let's say there is a mining pool or a mining organization that makes a contribution, let's say, to an organization like Satoshi Action Fund or the Bitcoin Policy Institute.
How is that really any different?
I mean, that seems like an investment in the long term benefit of Bitcoin.
[...] One of the ways I like to phrase it is like, I think if I'm a miner, which I am, right, I feel I have an obligation to protect the mothership.
And, you know, the mothership is the Bitcoin in the way that permissionless, censorship free, all these sort of attributes that we know and love.
Like I have an obligation to protect that. And so if I choose to protect it by looking at the transaction set and selecting a certain group of transactions that I believe protect the mothership in the long run and those attributes, then I feel that is the best economic decision.

Giacomo Zucco proposed a more colorful version of this argument.

There's nothing you can do about it

A common argument presented by spammers and spam enablers is that spam should be forgotten about because nothing can be done about it. This argument is simply wrong. In the past, spam has been stopped using filters and through the participation of miners. The arguments presented to argue that you shouldn't try to stop spam are divided into two categories:

  1. They can simply change a technical detail of the data injection method and circumvent filters, if filters are the method chosen to fight spam
  2. Miners are high-time preference greedy mercenaries

The second argument was already addressed and won't be discussed again here.
Regarding the first one, an important point about it is that it is a purely technical argument. However, spamming is not only a technical issue. Spammers are ready to pay high TX fees to get their spam into blocks mainly because they are hoping to make a profit out of the spam. The profits made by spammers rely on a network effect around the standard they adopted to spam. That is partly why spamming using extremely inefficient data storage methods continues to be dominant although more efficient "standards" to store data on-chain have been proposed. Updating default filters sends a strong message to signify that certain data injection methods are not desirable and that actors who rely on them are using non-desirable methods. Simply updating default filters in the past has worked, but for reasons unclear, Bitcoin Core developers have refused to consider spam as a significant issue since Taproot and did not take any action at all to update default filters.
Breaking the network effect of a certain "standard" of spam is critical as it forces spammers to adopt a new standard and resets the whole process of building an eco-system and creating a community around it. This also sends a strong signal to external sources of funding that might want to support spammers that future investments are at risk of being rejected by the network at any moment.

There is no other way to fight spam other than through a cat & mouse game and there will most likely never be an absolute solution to spam. That is because, by nature, spam will try to camouflage as valid content in order to waste and misuse shared network resources. The mouse needs to build ecosystems that can generate a profit out of the spam, that is always a costly endeavor that requires funding to build up a network effect around a source of revenue. The cat can easily become better at this game. Developing filters to identify and block new sources of spam is trivial as spammers will usually have to reveal how to identify spam in order to build marketplaces for example around it. All the types of spam of the 2023 wave use "explorers" to identify and present each type of spam, these software can be used to identify the spam.
If spammers eventually make spam so efficient that it becomes indistinguishable from Bitcoin currency transactions, so much so that it cannot be identified anymore, it will most likely won't be considered as spam anymore because of its efficiency. Until then, it is hard to imagine any path or solution other than continuously repealing spam.

Interestingly, spammers also propose that financial transactions should be updated to "improve the incentives and infrastructure for the transactions you DO want to see", namely Bitcoin currency transactions. This obviously contradicts the narrative discussed here, as it means that something can be done, as long as it is what the spammers want you to do. It is the only way to solve this issue according to them. The changes hinted at by spammers are significant as they would require a soft or hard-fork in order to make the native currency, bitcoins, of the network better compete with spam (which is a nonsense as Bitcoin currency transactions are much more efficient). At the same time, spammers insist that nothing can be done and that a kind of significant update is necessary.

Watch @LukeDashjr's interview during which he explains why although spam filters won't definitely stop spam in one day they are a necessary first step in the social consensus to eventually do so:

The 100 sats TX challenge

Francis Pouliot proposed a simple challenge to prove that some things can be done and that one of those things is simply introducing filters. In a tweet, he challenged someone claiming that "spam filters don't work", meaning that mempool policies don't work - see Mempool policy is censorship, to send 100 sats to a specific address.

This challenge aims at showing that filters do work because Bitcoin Core currently has a default dust filter that makes it very hard to get a 100 sats transaction relayed.

One of the participants to the conversation who accepted to take on the challenge has explicitly stated that they submitted such a transaction to a miner, allegedly Luxor, to mine this transaction as they know it won't be relayed by the network because of mempool policies. This action simply proves that mempool filters do work as they had to collude with a miner to get their transaction in a block, which didn't happen yet more than 4 hours after the challenge started because they need to wait for the miner they colluded with to find a block. This also means that the miner will have to continuously include this 100 sats transaction in their templates and that chances of this transaction making it through are as high as the hashrate share represented by the pool of that miner. This will of course mean that if transactions ready to pay a higher fee present themselves meanwhile, they might have to reject them to keep the 100 sats transaction if the block is already full. One of the participants who tried to do so actually explained that they tried sending a 100 sats transaction to a larger pool, ViaBTC, which would maybe get it through faster, but that it got rejected - most likely because of mempool policy (filters.)
The transaction will eventually make it through, but it required colluding with a miner that's willing to take it Out of Band, outside of the mempool, and that strongly limited the reach of the transaction since only a single pool is working on it which relegates it to the next block found by that pool. Currently, spam is mined by all miners which makes it present in blocks.

Miners can try to put whatever they want in blocks, the only workaround nodes have against that is to reject a valid block (meaning that it has a valid Proof-of-Work that answers the Difficulty condition) that contains some transactions or data proposed by a miner.

Making transactions more efficient on L1 will solve spam

The argument in support of UTXO aggregation that suggests it can mitigate spam on the Bitcoin network is a compelling one. Covenants, which are a type of script used to share UTXOs between users without requiring custodial services, would make monetary transactions more cost-effective and thus better equipped to compete against spam. However, an important detail that needs to be acknowledged is that covenants reduce the amount of fees miners receive, which goes against their economic incentives. Lightning, a type of scaling solution, also falls into this category as it reduces miner fee income.

This argument presents an apparent contradiction with the idea that spam filters are not economically feasible because they too go against miner incentives. This raises an interesting question: why would miners accept Covenants or Lightning but refuse to implement spam filters?
The answer lies in the fact that spam filters, like CTV and Lightning, ultimately improve network efficiency, which will have a positive economic impact on miners as it increases the overall value of the Bitcoin network. Mining is not just about earning fees; it also involves securing the blockchain through mining work. By improving network efficiency, these solutions make it more profitable for miners to secure the chain and receive block rewards while reducing their dependence on transaction fees. As a result, they become economically beneficial for all parties involved - users, merchants, miners, and Bitcoin as a whole.

"The best scaling solution is a chain without spam." - Greg Tonoski, 2024 January 30, Twitter.

"If you needed Vaults so bad, you would already use some."

Another trend emerging with the preponderance of spam is its growing use as an excuse for forcing fast adoption of scaling solutions. While some may argue that immediate action against spam attacks are necessary in order to mitigate challenges or other environmental considerations - this argument falls short given how such artificial spam scenarios are not necessarily representative of current real-world usage patterns within the Bitcoin blockchain ledger system for Bitcoin, a much more rational approach would be to address the spam directly first.

Some supporters of spam and scaling solutions have even gone as far as explaining that they intend to put pressure on Bitcoin through artificially generating large amounts of spams in order to push for fast adoption of many scaling solutions - this development presents a serious danger given how such artificial spam scenarios could potentially force developers into quickly accepting a scaling solution, which might not be fully ready, tested or that might introduce new weaknesses, efficiencies or even attack vectors. It is therefore essential to avoid such situations by ensuring an appropriate and measured response towards addressing any potential spam challenges in a responsible manner rather than rushing into quickly accepting many scaling solutions under artificial spams attack scenarios.
Scaling solutions are important and critical for the future development of Bitcoin, however, that does not mean that Bitcoiner should be forced into accepting all and any scaling solutions because of spam.

The following thread by @KLoaec, Wizard Sardine's CEO - the developers of the super interesting Liana wallet that already offers time-locks and recovery options akin to vaults, has an underrated thread about this subject:

High fees will solve spam

False. High Bitcoin fees don't stop spammers who have been the top payer for a year already. They increase their profit from clogging the Bitcoin network by exploitation of Segwit mispricing and other vulnerabilities that put genuine, monetary transactions at a disadvantage.

While it is true that spammers make short-lived attempts to profit, the history shows that they keep repeating them. Their payoff depends on collection of money from gullible or over-excited people and therefore is insensitive to level of Bitcoin transaction fee. The playbook looks almost the same every time:

  1. Raise funds for the operation (typically from so-called venture capital),
  2. Create something to gamble with (e.g. "collectibles", non-fungable-tokens - NFTs, derivatives). Give it new brand name. Advertise it, leverage industry-specific media, brands, influential figures etc. Claiming that is interesting art or technology (even better if somehow connected with Bitcoin),
  3. Collect money (in excess of Bitcoin transaction fees) from gullible or over-excited people duped into "investing" in faked art or technology (so-called bag holders).
  4. Repeat.

Cost of Bitcoin transaction fees does not impact profitability because proceeds are much larger. Victims transfer money in amounts that exceed the fees and ad campaigns. Spammers never spam without pushing narratives that provide excuses, e.g. "those cats in JPEGs are art". Spamming with random data would not be profitable.

In consequence of high fees Bitcoin is less decentralized. There are more and more "uneconomical UTXOs" with amounts that are not sufficient to cover the spam-inflated fee to transact. They are effectively removed from circulation. Their owners can't participate in the network while a few privileged ones gain exclusive access (power) what adversely affects decentralization. Segwit mispricing and other vulnerabilities make it cheaper to keep the barrier and concentrate power in fewer and fewer hands. They may be exploited (and fees remain high) as long as the struggle for power lasts.

Everything is good for Bitcoin

This statement would mean that Bitcoin is perfect and has no flaws or surface attack at all. This will most likely always be wrong. The reason why everything is good for Bitcoin is that Bitcoin can adapt, thanks to its nodes allegedly, against attacks and defend itself that way. But this requires an immune reaction that is currently considered as useless.
Nothing is indestructible, nothing is perfect. Bitcoin needs participants to actively defend it and address new attack vectors. That does not mean implementing soft-forks to defend against everything. Mempool policies, relay policies, long-term miner incentives, social campaigns, ... are all part of the toolkit that needs to be gradually deployed to defend the network. This toolkit can become increasingly more aggressive until the ultimate "defense", in the case of a miner concerted attack for example, where nodes would migrate to a new Proof-of-Work algorithm and reject SHA256 mined blocks for example.

Bitcoin core devs reaction

PR 29187: trying to fix datacarriersize

This section is a collaboration with @NTeterel and was adapted from this article he previously wrote

Several developers in charge of the most popular Bitcoin client, Bitcoin Core, were being heckled for their passivity towards Inscriptions such as ordinals and other arbitrary data backed used to build ponzis. Bitcoin Core is the most used 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 (see Detailed installation instructions to learn more about alternatives, and mainly the Bitcoin Knots client, that are not as spam friendly as Core).

Since Bitcoin Core is the most used node client, its default parameters and settings can be considered to be de facto the consensus rules of the network. Code changes to the Bitcoin Core client 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, Ava Chow, Russ Yanofsky, Gloria Zhao and Hennadii Stepanov.
However, here's the ranking of contributors ranked by the number of BIPs, improvement proposals, they spearheaded (source):

BIP lords

Luke Dashjr - the second largest contributor - sparked a controversy by inviting Bitcoin Core to act to stop Inscriptions and other wasteful transactions from attacking the network. Luke Dashjr's did so through a Pull Request, dated the 5th of January 05 2023. It is entitled: "Witness scripts being abused to bypass datacarriersize limit".
The description of the Pull Request goes as follow:

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:

As previously explained, filters (policy rules) hinders transactions undesirable by noderunners (each node runner decides for themselves their own policy) from being relayed by nodes into a block. For example, Bitcoin Core does not relay by default transactions weighing more than 100,000 vbytes, or those paying less than 1 sat/vbytes in transaction fees. This is enforced by default 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 Luke's PR, Datacarriersize refers to the "OP_RETURN" opcode (discussed in Satoshi inscribed on-chain so I should be able to do it too). OP_RETURN is an OP_CODE that 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 83 bytes per transaction that transaction emitters can use to add arbitrary data. That's enough to enter a SHA-256 hash (32 bytes) as well as an identification tag. OP_RETURN data will not be stored in the UTXO set (which is very harmful to the whole network) but it will still be stored on nodes forever.

What Luke means here is that he considers it a bug that Datacarriersize was not applied to all types of transaction data in the Segwit and Taproot soft forks. Basically, he is saying that Datacarriersize should have been updated to consider the new structures of data allowed by the Segwit and Taproof updates.
Fingers are often pointed at the SegWit and Taproot soft forks, which have increased and then eliminated the maximum size of transaction scripts. But that's a bit of a leap:

[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 is what has been exploited by BRC-20 and Inscriptions to circumvent protocol limitations and subvert the purpose of the Bitcoin protocol for toen and storage purposes. The whole DoS operation is being payed for by those being lured into buying all these so-called "projects".
This can be considered as an attack because these hundreds of thousands of voluminous transactions lengthen the initial synchronization time of a node or the IBD (Initial Blockchain Download), which already takes between 2 days and 3 weeks! Not to mention the premature rise in transaction fees and the cost of the quickly 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 arbitrary data. Unfortunately, Bitcoin Core's maintainers refused to send a strong message by updating the filters. Maintainers Andrew Chow, Gloria Zhao and Marco Falke have been 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 to redefine its definition 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). »

AJ Towns and Gibbs ACKed the redefinition.

This was around the same time Luke proposed to extend the applicability of datacarriersize to also catch inscriptions. Then Gloria Zhao and Ava Chow (Bitcoin Core maintainers with commit access and merge rights) used that new meaning of datacarriersize as an argument to reject the fix.

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. Several noderunners have accused maintainers of insidiously reducing the scope of -Datacarriersize this way. The aim was to justify inaction on new techniques of data injection into transactions. After the discovery of this stealth change, maintainer Achow made the claim that changing the documentation was somehow a way of eliminating the bug...

This contortionism aimed at protecting the inscriptions’ circus is worrying. Faced with this Commedia dell'arte, Luke has taken the lead by developing the "ordirespector" patch. 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 spammy transactions.

What can you do about it?

A more detailed version of these instructions can be found here.

As a noderunner

  • Use Bitcoin Knots 25.1 (All spam filters are up to date)​​​​​​​
  • Set the following configuration options: -permitbaremultisig=0, -datacarrier=0 (if you are using knots 25.1 or later)
  • Keep asking node software providers (their telegrams, twitters, nostrs) to introduce GUI options for filtering [Jester] - show there is demand.

Running a node on a Raspberry Pi?

Don't forget that if you don't even use your node to broadcast your transactions and check the state of the chain or TXs of interest to you on-chain, your node plays no role at all in the network.
It is true though that if it's a full node, it could at least help someone synchronize their own node at some point in the future, which is the reason why it is important to keep the ability to run nodes affordable for most users.

As a miner

  • Point your hashrate to Ocean ("ocean" or "core+antispam" block template)​​​​​​​

As a developer

As a pleb

  • Be vocal about your concerns, join discussions[1] ,[2] [3], ask questions, share knowledge. Remember that discussions are not always there to persuade the detractor, but to form an opinion of observers. Your voice is the market force.

History of spam on Bitcoin

Free relays > Whitelists > Free relays

  • It appears that Satoshi initially wanted to develop and allow for many types of TXs on Bitcoin
  • However, he was at some point convinced by Gavin Andresen that was a slippery slope and opened the doors to DDos attacks
  • Satoshi then moved back to a whitelist model that only allowed certain types of OP_CODES and TXs on Bitcoin
  • Under the pressure of some miners who decided to mine any type of TXs, the whitelist model was then abandoned again

The rise of Out Of Band transactions

The 22nd of February 2024, Marathon, a US based miner that holds around 25 exahash (by March 2024) officially launched a service designed to allow anyone to directly submit transactions to them, completely circumventing mempools and relay policies.

This service mainly targets Non Standard transactions. For example, it was used to mine block 832,849 which is th biggest block to date (3.99 MB). It only contains 7 transactions, among which a single one (an Inscription) occupies most of the block.

Block 832,849

A block containing 3097 transactions shared to the mempool was expected instead of this one.

Noteworthy cases of massive broadcasts of non-payment TXs

BitDNS

In September 2010, a proposal was made on the BitcoinTalk forums about a DNS protocol that would rely on Bitcoin. A quick description of this project is provided here from the bitcoin.it wiki:

Bitdns was a project with the goal to extend Bitcoin's technology to a domain name service, expanding the software to support transactions for registering, updating, and transferring domains. The project eventually became an altchain with its own altcoin, known as Namecoin.

Satoshi's comments about BitDNS

Counterparty

See The OP_Return Wars of 2014 – Dapps Vs Bitcoin Transactions and Developers Battle Over Bitcoin Block Chain.

SatoshiDice

Do you think SatoshiDice is blockchain spam? Drop their TX's - Solution inside. SatoshiDice spam in mempools was the primary concern. Unlike other types of spam, SatoshiDice didn't append arbitrary data to transactions recorded in the main chain.

Omni

Dominating OP Returns: The Impact of Omni and Veriblock on Bitcoin

Veriblock

Ibid.

Articles and content about the issue

Other references

Data Insertion in Bitcoin's Blockchain.

License and acknowledgement

  • MrGnome for the rigorous review
  • @leo_haf for his direct contributions to this page
  • @GregTonoski for his many contributions to this page

License: CC0-1.0 WTF happened in February 2023 by @piratebiscuit is marked with CC0 1.0