LOPP_RETURN Wars: The problem is deeper than spam filters, Stratum v1 needs to die

It's an open secret that one of Bitcoin's pillars never worked as Satoshi predicted at the time he designed Bitcoin. It faltered even before Bitcoin started getting any real traction, and this failure has been part of the landscape for so long that we normalized it, like a crack in the wall that's been growing for years but we learned to ignore.

It doesn't seem to have any relation to the current mempool policy debate (better known among the plebs as "spam filters"), but it's actually at the center of the issue.

I'm obviously referring to mining decentralization. Or the lack thereof.

Satoshi's Original Miscalculation

It is well-acknowledged today that Satoshi didn't predict the raise of mining pools. If you read the whitepaper it seems clear that he thought the network would work on what today is called "lottery mining", where anonymous small miners with an imperceptible share of the total hashrate would be finding blocks at random, maybe just once in their lifetime.

This property of the system was the basis for Bitcoin's primary defense system and censorship resistance: it's very difficult to do something like enforcing OFAC compliance lists or a malicious fork if literally any Bitcoin node around the world could be the one that mines the next block. In other words, for mining to work "as desired" by Bitcoin's inventor, you should not be able to predict which nodes would mine the next hundreds of blocks nor identify who they are.

The following are a few fragments of the whitepaper that highlight the importance of the node's involvement in the mining process:

As we all know Bitcoin mining stopped working like that very early on. In the times of Laszlo Hanyecz and ArtForz each of them held slices of the total hashrate comparable to Foundry or AntPool today (as a result of having independently developed GPU mining). Satoshi even admonished Laszlo over email for mining too many blocks, which gave birth to several Bitcoin Pizza transactions in an altruistic effort to decentralize the issuance of those early coins.

On November 27th 2010 the first ever mining pool launched (Braiins, formerly Slush Pool), and a couple of years later Stratum v1 was finalized and took the mining scene by storm. The rest is history.

As a Bitcoin miner there are obvious reasons for joining a pool and sharing rewards, but Stratum v1 has a major flaw: only the pool operator runs a bitcoin node, and miners only plug their hashing machines, completely unaware of the Bitcoin protocol.

This meant the death of the "miner" role as was understood at the outset: it was split into the hasher that just plugs his specialized machines to the power outlet to receive periodic payouts, and the pool operator that runs the Bitcoin node, takes custody of the rewards and organizes the payouts.

Separately, the role of the node runner emerged. These are users that maintain a node to verify their own payments but who don't "contribute CPU power to keep the chain honest", and today make up the absolute majority of the bitcoin nodes.

Even though in theory hashers can switch pools on a whim this architecture did set the stage for a mining landscape centralized on just a few big players. Today adding more CPU power to the Bitcoin network (or rather ASIC power) no longer contributes to keeping the chain honest. That rests on the benevolence of our pool operator overlords:

While it's true that most developers acknowledge this as a problem and have devised a few solutions (example above) they generally don't feel like it's up to them to fix this issue. At the end of the day working as a software engineer or an applied cryptographer is very different than going into the ruthless and unforgiving business of Bitcoin mining.

But to this day mining centralization is still a big problem. And even more worryingly, it led to a second order effect that has won a lot of developer's hearts and minds...

The Siren Song of "Mempool Consistency"

In summary, mempool consistency is a scenario where all nodes in the network run the same mempool policies as the pool operators. It turns out that when that happens the network can run much smoother and makes the lives of the developers building on top of Bitcoin much easier.

Over time they learned to accept mining pool centralization as a given, and they started to rely more and more on this phenomenon to build advanced Bitcoin features. I'll cover one of the first ones, and arguably maybe the most important:

The Poster Child of Mempool Consistency: Compact Block Relay

BIP-152 (Compact Block Relay) was proposed in 2016 by Matt Corallo and made its debut in Bitcoin Core 0.13. Until that point when a pool operator found a block and broadcasted it to the P2P network nodes relayed the full block along with all the transactions in it.

CBR proposed that nodes just relay the block header (only 80 bytes) and let each node reconstruct the full block locally using the unconfirmed transactions it already has in its own mempool. CBR fixed the traffic spikes that plagued the old P2P network when a new tip was found, and it's considered a positive nudge towards keeping mining decentralized: slower propagation means that on average small miners with bad connectivity would see more of their blocks "orphaned" compared to the large pools peered directly over high-speed links.

Another example of something that really benefits from mempool consistency are the fee estimations, which in turn are important for the smooth operation of L2 protocols, because all of them are time-sensitive and require timely confirmation of their onchain transactions.

Does running custom mempool policy such as not accepting inscriptions ruin CBR for your node?
Not exactly, because when a node discards an unconfirmed transaction due to violating a policy rule it doesn't remove it altogether. It keeps it around in a secondary mempool precisely for the sake of Compact Block Relay, expecting that it could still be mined, but crucially it is not relayed to your peers.

This is not the case for transactions that violate a policy that is enforced by a supermajority of nodes, because in that case it's unlikely that any of your peers will ever relay these transactions to you in the first place.

Mempool Consistency's Kryptonite: Out of Band Transactions

If "mempool consistency" means that all nodes run the same policies in order to see the same transactions, nothing fucks it up more royally than when a pool operator includes out-of-band (OOB) transactions in a block they mined.

Ultimately I believe this is the primary reason why the developer class has been so opposed for the last two years to keeping mempool policies (colloquially known as spam filters) up to date, and act so viciously against node runners taking the matter into their own hands.

It makes sense from their point of view. Their primary concern is mempool consistency. They clearly cannot force an old boy's club of large pool operators to run sane policies, so to keep all mempools equal the path of least resistance is taking the policies away from node runners, who are perceived as being less informed and easier to lead as a herd. Their end goal is that pool operators don't have any reason to accept OOB transactions.

This is also why they greatly exaggerate the extent to which mempool policies are being bypassed in the wild (see also this onchain study on non-standard transactions from @0xB10C which comes to the same conclusion).

Mempool Policies: debunking the FUD narratives

There is such a level of shitfuckery surrounding mempool policy that I need to dedicate a chapter explaining what it is and debunking malicious narratives. To start, I think it's helpful to compare them to consensus rules.

A consensus rule is a check performed either on a block header or any of its transactions that will flag that block as invalid and rejected by all nodes. An example of a consensus rule is that a transaction may not create sats out of thin air. If such a transaction were to be included in a block by a pool operator the whole block would be rejected.

A mempool policy is a check performed on a newly seen unconfirmed transaction that may prompt your node to not relay it and not store it in its mempool, but otherwise it's a valid transaction by consensus rules. An example would be a transaction that is trying to pay a fee of 0 s/vB, or a transaction with an OP_RETURN larger than 83 bytes. Mempool policy is outside of consensus and thus each node runner can actually run whatever policies they want in practice. A few of them are configurable in the bitcoin.conf file, and Knots has more of these settings than Core. Luke-JR recently drove this point home by doing a live walk-through on how to add new mempool policies to Knots.

Mempool policies have been in use in Bitcoin Core since 2010, and according to developer Antoine Poinsot they have three primary roles: discouraging malicious DoS transactions that can crash nodes (Denial-of-Service), discouraging old kinds of transactions that are about to be invalid in an impending soft fork (what he calls "upgrade hooks"), and finally "nudging behavior to midly deter certain activities".

As you can see developers don't think mempool policy is "useless" or "ineffective", in fact it's an important tool in their belt on which they rely a lot. But if pool operators don't respect a certain policy, or developers expect they won't respect it in the future (what they call "incentive-incompatible policies") they'd rather remove it from Core than sacrifice mempool consistency.

At this point I hope I've made the connection apparent between pool operator centralization and developer's optimization for mempool consistency.

Now it's time to explore the point of view of the "filterbois", which is based on reverting the mining centralization we lost almost since the start of Bitcoin instead of optimizing for mempool consistency.

The Anti-Spammer Response: DATUM, not any particular policy

Since October 18th 2024 you can solo-mine with your Bitcoin node and still pool rewards with a group of other hashers, a monumental feat that had never been possible before in the history of Bitcoin. That was when Ocean launched its DATUM mining protocol.

DATUM pushes the running of the Bitcoin node back to the hasher, giving individual hashers power again about what transactions they want to include in their blocks, what forks they want to signal support for, etc. The pool only takes care of coordinating the split of the reward, and making sure that miners don't cheat each other by submitting shares to the pool while paying the full reward to themselves.

DATUM makes it possible for the roles of the pool operator and the hasher to merge again into the unified role of the miner. This means the individual "CPU power" of each hasher contributes again to keeping the chain honest instead of selling their shares to a large pool operator.

There are other things that excite me about DATUM. For instance it wouldn't matter if a DATUM pool went over 51% of hashrate as the pool doesn't control the Bitcoin node.

Another super cool thing is that DATUM works with mining at any scale. If you are already a node runner today you can start mining at home with a BitAxe for about $150, feeding it your own block templates and participating in the network as a real miner at a small scale.

While most developers won't agree with me, I posit that destroying pool operator centralization is a much more worthwile endeavor than protecting mempool consistency at all costs. I really like how this tweet summarizes the tradeoffs at stake:

I invite both hashers and node runners who read this article to look into DATUM to become sovereign Bitcoin miners. And if you are a pool operator, I would like you to start thinking about phasing out Stratum v1 in favor of DATUM or Stratum v2.

Bitcoin needs Stratum v1 to die.

DATUM vs Stratum v2?
The main reason I focused on DATUM in this article and hardly even mentioned Stratum v2 is because it's live and ready to use.

Jason Hughes, VP of Engineering at Ocean recently went over why they chose to build a mining protocol from the ground up instead of adopting Stratum v2 in a presentation he gave at the 2025 BTC++ conference in Austin.

Next Up

There's a big topic I had to leave out of this article or it would have been twice as long. It's the common claim that "any transaction that pays fees is good for Bitcoin". This is an discussion mostly centered around economics so I prefer to do it in two separate parts.

The next article will give a proper definition of Bitcoin's security budget, argue why spam is bad for the security budget and analyze a few Keynesian proposals to "fix" the security budget, most notably the "demurrage" and "tail emission" proposals by Peter Todd.