Inside your Bitcoin node there are two wolves
One of them is the consensus rules about what makes it into the blockchain. The other one is your mempool policy about what makes it into the blockchain.
The wolves are not the same. Which one is Bitcoin?
Consensus Rules: The Day Wolf
Consensus is a good wolf. It may be savage, but it only kills and eats transactions that don't follow consensus rules.
Every transaction included in the Bitcoin blockchain follows a set of rules that make up what we call Bitcoin. If you run a node and you have an up-to-date copy of the Bitcoin blockchain your node agrees with all the other nodes about the rules transactions must follow. This is consensus.
There are a lot of consensus rules. People like to argue about them. Disagreements lead to forks and forks are scary, so everybody pays attention to the Day Wolf. It's a big hulking animal that's impossible to ignore.
Mempool Policy: The Wolf of the Night
Mempool policy is a mysterious wolf. A lot of Bitcoiners don't even know it exists, don't even know the difference between a mempool running on their node and mempool.space. Not too many people notice how the Night Wolf1 feels about things.
Unless you send your transactions directly to a miner, you are probably relying on a transaction relay network created by Bitcoin nodes all around the world. If you are running a Bitcoin node with a mempool, odds are you are participating in this transaction relay network.
Nodes make connections to other nodes and a lot of smart people have figured out how to make sure that when a new block gets mined, your node has already heard about almost all the transactions it contains. Your node doesn't have to start downloading and verifying like mad when a new block shows up because it has a mempool where it keeps unconfirmed transactions it's heard about, just waiting for them to show up in a block.
In many ways, the Night Wolf is the Day Wolf's younger brother: the Day Wolf is in charge and the Night Wolf can't do something the Day Wolf doesn't agree with. Your mempool isn't going to let in any transactions that violate consensus rules.
But does the Night Wolf have to let in every valid transaction it hears about?
When the Night Wolf growls
Maybe you've heard a little bit about the debate around ordinals and filtering and spam and so on.2 This is a debate about the Night Wolf.
You see, it turns out that some people don't like that other people are broadcasting transactions full of crappy random data (like pixel pictures of rocks) and they want to use their mempool policy to make such transactions harder to get into the blockchain.
So here's what they do: they go beat the Night Wolf and tell him that he has to slaughter any transaction he comes across that meets their criteria of what should be excluded.
They change the policy rules of their mempools to exclude transactions that are consensus-valid but, for example, that have more than a certain amount of data in the OP_RETURN.
The Night Wolf in their node dutifully becomes a wild-eyed killer.
The Night Wolf has always been a killer
He's a wolf, people. He kills things. That's what wolves do.
Mempool policy has always3 been more restrictive than consensus rules.
It turns out there are already a host of mempool policies that let the Night Wolf slaughter consensus valid transactions so that they never move beyond his mempool. Here's just a few examples of valid kinds of transactions the average Night Wolf refuses to relay:
- transactions that are big
- transactions with a ton of signatures might
- transactions with an nVersion that isn't 1 or 2
- transactions that are worth less than it costs to get them mined
- transactions that are bare multisigs
So what's the big problem with letting people add a few more policies to their mempool and make their Night Wolf especially mean and nasty?
The Day Wolf is stronger than the Night Wolf.
If a transaction is not valid by consensus rules it won't make it into a block. That's Bitcoin.
Bitcoin is able to do this thing we call soft-forking because of this fact. A hard fork is when you change the consensus rules so that the Day Wolf has to spare transactions he used to kill. A soft fork is when the you make the consensus rules more specific so that the Day Wolf can still kill all the transactions he used to kill, but now he gets to kill some new ones.4
So the Day Wolf--consensus rules--controls what the blockchain is and this is as it should be.
The Night Wolf can't make the Day Wolf change his mind. But can the Night Wolf cause a soft fork by killing certain kinds of transactions before they get to the Day Wolf? Could you use mempool policy to mimic the effect of a soft fork?
The answer is no. No matter how strict you make mempool policy, as long as a small percentage (I've read some things that say 2 or 3 %, while others say more like 30%) of nodes are still relaying transactions you don't like (and are consensus valid), such transactions will make it into blocks. And once they are in blocks, the Night Wolf is powerless.
But what if all the nodes give in and embrace their own inner Night Wolves?
People start emailing the Day Wolf
If there are people who want to spend money to get consensus-valid transactions into the blockchain, there will be miners who want to earn that money. That's what the business is.
As of March 2024, there are at least 5 publicly available transaction accelerators run by mining pools (AntPool, F2Pool, ViaBTC, Binance, Mara).
Transaction accelerators are generally seen as a bad thing for Bitcoin because they might lead to centralization. When some miners see transactions that the rest of the miners don't know about, they might get an edge. And miners with an edge quickly become miners with more hashpower. Now we have to deal with a new animal: centralization.
Centralization is like a big evil bear that wants to come eat up both wolves and all the nice little lemmings that play with them (that's you and me).
Why not just let the two wolves become one? (Relay all valid transactions?)
Since we don't want to get eaten by the evil bear of centralization, why don't we just make sure that mempools will accept every consensus-valid transaction? If we did that, nobody gets an edge, transaction accelerators return to just being a tool for people who don't know how to use CPFP and RBF and we end up with just one wolf.
@benthecarman wrote a Bitcoin Core PR back in May 2023 to allow nodes to reduce some of the major differences between the wolves and the discussion around it is a pretty quick primer on what's at stake.
Inside Bitcoin culture there are two wolves
Bitcoin achieves an incredible thing: it manages ensure that a utxo created in 2009 with who knows what kind of weird experimental script thingie (because it was all a weird experimental thingie back then) can still be spent today despite all the many clarifications that have been made to the consensus rules.
But this means the Day Wolf can go berzerk. He still needs more training. And the Night Wolf can help with that.
EXAMPLE:
Pre segwit transactions can be made in such a way as to put a huge validation burden on nodes (quadratic hashing problem). The consensus rules haven't changed to prevent this because it could potentially make some valid utxos impossible to spend. A number of mempool policies exist to reduce the risk that such transactions will propagate through the network.
Additionally: Bitcoin is a live network, securing hundreds of billions of dollars of value and we still make changes to the rules without anyone actually being in control of it.
EXAMPLE:
All transactions have a nVersion field. After segwit, this field has been reserved to facilitate future upgrades. The Night Wolf crunches up any transaction that has anything other than 1 or 2 in its nVersion to preserve this ability. Eventually, we want to be able to "turn on" some functionality by putting a 3 or a 4 there, but it needs to be held blank until we all agree on what that functionality is going to be.
The two wolves exist pretty much because Satoshi made mistakes in its early days and wrote consensus rules that allowed dangerous transactions or didn't anticipate the ways in which the project would grow. Bitcoin culture refuses fix the problem by changing the consensus rules if it results in making it impossible for someone to spend their money or if it means an increase in centralization.
The Moral of the story5
It's okay for mempool policy to be more restrictive than Bitcoin's consensus rules, but it should be as close as possible and anytime miners are mining lots of transactions that most mempools reject, it's probably time to reevaluate.
Network behavior is one of the few bits of friction driving good technical design rather than "move fast, break things, and force everyone else onto my way of doing thing rather than discussing the design in public" --gmax, 2015
In wolf terms this means: the Night Wolf can get big and ferocious, but he needs to always remember that he isn't as strong as his older brother.
If you want to learn more about this, you should read Gloria Zhao and Murch's Waiting for Confirmation to get started down the rabbit hole.6
Footnotes
-
The Night Wolf is a better name for the mempool. ↩
-
There's been so much conversation about filtering and spam that I decided it's time we had some new metaphors to expand the semantic turf this conversation inhabits. Therefore, you are all going to get spirit animals. ↩
-
I'm not actually sure if mempool policy was more restrictive than consensus rules in early versions of bitcoin, but it has been since at least segwit. ↩
-
Here's an easy way to remember the difference: hard fork = nicer wolf; soft fork = meaner wolf. If you think I'm stretching this analogy way too far...just wait. I haven't even gotten started yet! ↩
-
I was going to write just a straightforward description of all this, but my cousin Mathilde is really into wolves and convinced me that it would make more sense if I used wolves to explain it. I listened to her because she's the only person who ever helped me to understand the Fed's Reverse Repo Facility and she speaks Latin. ↩
-
Maybe I should have made this whole thing a rabbit metaphor... ↩
-permitbaremultisigthat’s enabled by default but can be used to disable relay of all bare multisig outputs.