Cluster Mempool Explained with Pieter Wuille | SLP730

**Pieter Wuille** (0:00)
I would go as far as saying this is the entire reason why Bitcoin has proof of work. The point of having proof of work is that anyone can join the mining market. Bitcoin's decentralization and censorship resistance ultimately boils down if things go really wrong. The final protection is you can become your own miner, maybe even at a loss, but hopefully not at a big one. What is it that incentivizes existing large miners to basically accept every transaction? It is the knowledge that if they start reliably censoring some transactions that have economic demand, someone will just pop up and mine them anyway.

**Stephan Livera** (0:43)
Hi, everyone, and welcome back to Stephan Livera Podcast. Today, I'm joined by Pieter Wuille. He is a long time Bitcoin developer, researcher, and he is working at Chaincode Labs. And we're going to be talking a bit about Cluster Mempool, which is a new project that is landing in the new version of Bitcoin Core V31, I believe.

**Pieter Wuille** (1:02)
Correct.

**Stephan Livera** (1:02)
So, Pieter, welcome to the show. And let's start with why. Why were you interested in this project of Cluster Mempool?

**Pieter Wuille** (1:09)
Yeah, so you call it a new project. We started this just about three years ago. And the immediate motivation for this project was a talk that Suhas gave here at Chaincode Labs about some of the existing issues with the current Mempool design. The immediate motivation was this example of actually you can end up in a state today in a Mempool. Obviously, not likely would need a pathological adversarially constructed situation, but where the very first transactions that would be evicted if the Mempool fills up, the first thing that gets evicted is actually the very first transaction you'd want to mine. And this is obviously undesirable. It's undesirable for miners, but it's actually far worse than that. When the network is sort of unable to reason about a proper profitability of transactions, and because obviously you'd want eviction and mining, even if you're not a mining node, like you would want the things you evict to roughly correspond to the very last things a miner would want to include.
And so that was the motivation to show like actually the current design we have is broken in many ways. That doesn't necessarily mean exploitable, but it sort of makes it hard to reason about things. And we wanted to address that, came up with a cool design, and it grew into something that ended up replacing everything in the Mempool basically internally, touching on some relay policies that change along with it. And yeah, so it's been merged now. It will be in Bitcoin Core 31, which is slated to be released next month, I think. So pretty excited about that.

**Stephan Livera** (3:03)
Great. And so just to motivate this for listeners, why does this project matter for everyday Bitcoin users? What is the impact that they might see? Or basically, what is the impact that an everyday Bitcoin user will see here?

**Pieter Wuille** (3:16)
Hopefully nothing. I think the motivation is more a long-term health of the network question than it is directly improving things for users. Now, they might see a few changes. The most noticeable, I think, is how today, so up to the current Bitcoin Core release, we have relay policies that include ancestor limits and descendant limits. That means any transaction together with any and all of its unconfirmed ancestors cannot be more than 25 And similarly, a transaction together with all its unconfirmed descendants cannot be more than 25 transactions.
And sometimes you see these peeling chains of someone makes a transaction, sends a change back to themselves, use the chain to do another payout, sends it back to themselves. Hopefully, they would batch this and turn it into a single transaction. But if they don't, this sort of chain is limited to 25 transactions at any given time, right? It's not that it's impossible to peel further, but you'll need to wait for some of them to confirm before the later ones propagate across the network. And this changes. With Cluster Mempool, there are no more ancestor or descendant limits, instead, there are cluster limits. Think of it as a...
It's your... Continue with the analogy of ancestors and descendant in a family tree. Cluster is just the widest possible extended family thing. It's like your parents and children, your grandparents and grandchildren, also aunts and uncles, nieces and nephews, their parents, their children. Anything that is related through any combination of is parent of or is child of. And you can sometimes do see fairly complicated things where you have one user that pays a number of other users, and then they spend those coins together with another output that they got from yet another party. They all become related in a cluster. And so in Cluster Mempool, we have a limit of 64 transactions in a cluster. That's a number we picked based on performance characteristics of the algorithms inside, similar to how the ancestor and descendant limits of 25 in the past were picked based on... Well, these are the things we can sort of efficiently reason about still without the computation time for nodes blowing out of the water. Yeah. So the most obvious direct impact is probably you could build these peeling chains up to 64 rather than 25 But it's not like just increasing the number because you also have this extended family thing that gets countered along with it.