Episode 50: Death To The Mempool, Long Live The Mempool

Aaron van Wirdum Live from Utrecht, this is Bitcoin Explained. Hello. Hey, Sjors.

Sjors Provoost What's up?

Aaron van Wirdum I'm doing well. We're still in Utrecht, as I just said, but only for a couple more days. I'm on my way back to El Salvador, essentially, for a couple of conferences. And I think you're going to be traveling as well.

Sjors Provoost Hopefully, if it's warmer.

Aaron van Wirdum And if the COVID situation allows it.

Sjors Provoost Well, wherever the COVID situation allows it.

Aaron van Wirdum So anyways, the reason I mentioned that is because we are recording this episode probably… We're recording this episode ahead of time. We're recording this episode probably at least two weeks before it's actually published. And we're going to discuss a thread from the Bitcoin development mailing list that was published a couple weeks ago.

Sjors Provoost That's right.

Aaron van Wirdum So by the time people are listening to this, they are going to be hearing a discussion on a thread that's at least a month old.

Sjors Provoost But it's good. You need to be reminded occasionally of the things that are important. And besides, last episode, I think we talked about something from three months ago.

Aaron van Wirdum Yeah, if you want fresh content, Bitcoin Explained is not a place for you. But if you want exciting and interesting content and… from the top expert in the space, Sjors Provoost, then Bitcoin Explained is perfect.

Sjors Provoost If you want it translated by the top journalist in the space, then Bitcoin Explained is also perfect.

Aaron van Wirdum Stop it. All right, Sjors, enough about that. Let's get to the point. We are going to be discussing a thread. Do you have a name of the thread in front of you?

Sjors Provoost That's right. It's called Death to the mempool, Long Live the mempool.

Aaron van Wirdum Right. It's a proposal to basically abolish the mempool, right? So let's get... Who started the thread?

Sjors Provoost niftynei. He's a— she's a C-Lightning developer.

Aaron van Wirdum Yeah.

Sjors Provoost Blockstream. Now, we don't really know whether this proposal is super serious or more of a thought exercise, but it resulted in a very interesting discussion.

Aaron van Wirdum Right, yeah, when I first when I saw the thread it felt a little bit like homework; it felt a little bit like you're making like an exam where the teacher says all right, why don't we redesign Bitcoin to get rid of the mempool? And we'll explain what the exact proposal is. And then you as the students have to sort of figure out why that's not a good idea. That was sort of my first reading. That's sort of what it did with my brain.

Sjors Provoost Yeah, and it helps to remind you why this mempool is useful in the first place.

Aaron van Wirdum Right, exactly. The interesting thing for me was, you know, I... I could figure out, you know, one or two reasons why I didn't, you know, like the proposal, but then the threads kept going for a while with more reasons and counter-arguments, and it became more interesting than I sort of anticipated at first, I would say.

Sjors Provoost Yeah, and then also lots of semi-related interesting proposals, for example, by Zmn, Z-M-N-S-C-P-X-J, the pseudonymous.

Aaron van Wirdum Okay, so let's just get into it.

Sjors Provoost Yep.

Aaron van Wirdum First question. What is a mempool?

Sjors Provoost So the mempool, we talked about the mempool at least in episodes 19, 26, and 38. I don't know if you want to listen to those. The mempool is a place where…

Aaron van Wirdum It's incredible how you remember all of our episodes just from the top of your head.

Sjors Provoost Absolutely.

Aaron van Wirdum That's how a wizard's brain works.

Sjors Provoost So basically, well, transactions go into blocks, but before they go into blocks, they have to be proposed somehow. And the way people propose transactions is just to send them to everybody and everyone. And then every node has a list of transactions that are not yet in a block, probably about 300 megabytes worth of those, depending on the mempool weather, as people would call it. And this is generally kept in memory, though, as Eric Voskuil pointed out in the mailing list, it doesn't have to be done in memory. His Bitcoin client, Libbitcoin, keeps it all on disk. It doesn't really matter. I mean, the way he would describe it…

Aaron van Wirdum You could probably store it in your memory.

Sjors Provoost No, I have actually quite a bad memory.

Aaron van Wirdum No, no, we've noticed, Sjors, your memory is... Anyways, go on.

Sjors Provoost So basically, I mean, what he would say is you can, all these transactions that are proposed transactions, you can just put them on a disk and then you can say, okay, here's a block and the block points to all these transactions now. That's essentially what a block is. Just points to all these transactions and then you're done. So yeah, I guess that's the mempool.

Aaron van Wirdum Yeah, that last part about how Libbitcoin works was a little bit of a sidestep. But in general, the mempool is just a collection of transactions that nodes keep and that miners, well, keep and forward to other nodes, just the nodes that are sort of propagated over the network. And then miners use their, every node has its own mempool. And then the miners use their mempool to select transactions, which they're going to mine on and hopefully become the new block.

Sjors Provoost Yeah. But in general, most of the transactions that are in your mempool will eventually be in a block, and that's kind of important for the discussion ahead.

Aaron van Wirdum So what is the problem?

Sjors Provoost Well, there's many problems.

Aaron van Wirdum What is the problem that this mailing list thread seeked to address and wanted to solve?

Sjors Provoost Well, one problem is bandwidth. So at least as it was explained, like sending all these transactions around all the time to all your peers uses up quite a bit of bandwidth. And the second is that, and that's I think what we covered in episode 38, we discussed then there was a bug in Bitcoin Core with how the way RBF replaced by fee was implemented. And then we tried to explain how that impacted Lightning in unpleasant ways. And we failed to explain how that impacted Lightning because it is very complicated. And this complexity is the problem. So it is very difficult for people, especially working on things like Lightning, to make the protocol safe against all the little gotchas that exist in this mempool. The mempool looks very simple as we just described it, but there's lots of intricate details that you really have to understand. And if you don't understand those correctly, then what could happen is you try to broadcast a transaction, for example, to take money back from your channel because somebody cheated on you on the channel. And then that other person can do some shenanigan, put some other transaction in the mempool or lots of transactions in the mempool. And all of a sudden, your transaction never gets confirmed and theirs does. And this is very difficult to reason about. And so that's why the suggestion was, why don't we just get rid of the mempool?

Aaron van Wirdum Yeah, I think the heart of the problem, which you just explained, is that… Sometimes it's important that your transaction actually makes it in the mempool at least but there are restrictions on how big everyone's mempool can be because everyone has to do that and that just requires resources so there's a cap on that but because of that cap, that means your transaction can't always get in, and that opens the door to niche types of attacks, and we're not going to get into that in detail but…

Sjors Provoost Yeah, and it's worse than just having a cap on the size of the mempool. There's all sorts of rules. Like if 100 transactions are related to each other and you want to replace one of those 100 transactions, then that can cause problems too.

Aaron van Wirdum There are a number of limitations that sort of ensure that nodes don't get overloaded, but these limitations then open the door to potential weaknesses or attacks. That's a very short version.

Sjors Provoost And this is also, of course, an incentive problem, really because the incentive for things like Lightning is to you know be secure for the users of the Lightning channels but the incentives for the people running a node, well they're just having that mempool there partially altruistically they have slightly different incentives. They don't want to get overloaded, but their incentive is not to protect the Lightning network and this [unclear]— this can cause some friction because the incentives are slightly different.

Aaron van Wirdum Okay, so what we've now— we've now explained in our great podcast, Bitcoin Explained, what the mempool is and what the issues with it are in some circumstances. And then this thread offered a solution. So what was the solution that was proposed?

Sjors Provoost Well, get rid of the mempool.

Aaron van Wirdum Get rid of the mempool altogether.

Sjors Provoost Yeah. And of course, that immediately poses a question. If I have a transaction and I wanted to get it in a block, but there is no mempool, well, then what do I do? Do I just scream on the streets?

Aaron van Wirdum I mean, in a way, that's actually how it works now. You're just screaming it to the network.

Sjors Provoost Yeah, that's correct.

Aaron van Wirdum Screaming to the streets is probably not an upgrade, but they proposed, why not just send your transaction directly to a miner?

Sjors Provoost Exactly.

Aaron van Wirdum Because miners, that's the one that actually needs the transactions. They're the main one. In a way, the only ones, but definitely the main ones that need a transaction because they're the ones creating blocks. So why don't we create a system where we send the transactions directly to miners, right?

Sjors Provoost Yeah. And of course, that brings the question of, well, probably to a mining pool, not to an individual miner. But still the question then is, well, who are the miners? How many are there?

Aaron van Wirdum Where do you send the transactions?

Sjors Provoost Where are they? Yeah. And do we want to send it to their home address by envelope? Or how are we going to do that? And so the proposal there was to say, well, we want to preserve miner anonymity. That was still a goal. And the way it could be done is miners could publish an onion service, so a Tor service, a hidden service, like a dark website, I guess. And to this dark website, quote-unquote, you send your transaction. Automatically, of course, your wallet might have a list of 100 different miners, and it would just send the transaction to all 100 of them. That would be the idea.

Aaron van Wirdum Yeah, so if you're a miner, or maybe we should say more specifically, actually, if you're a mining pool, because that's sort of the point, that a lot of the transactions— a lot of the blocks, all of the blocks, essentially, I think, are currently mined by mining pools. And as long as there's a manageable number of mining pools, then you can get all of their addresses and send it to them directly.

Sjors Provoost Yeah, that's the proposal.

Aaron van Wirdum When I say addresses, like you mentioned, it's like a Tor address. Yeah, like a hidden service.

Sjors Provoost So this poses a problem, or a number of problems.

Aaron van Wirdum Are we ready to get into the problems? This was the proposal, right? I think we captured the essence of the proposal. Rather than having a mempool, rather than having every node on the network transmit every transaction to everyone else, to every other node, rather, you know, as a user sending your transaction just to the Bitcoin network, instead, you'll send them to a number of mining pools.

Sjors Provoost Yeah, and one thing you can do there also is you can have, since you have a communication channel with the miner anyway, you can ask what fees they want, you know, rather than guessing. That could be an advantage or not, but that's another possibility. So this gives you a little bit better. I mean, the reason why this might be useful is it gives you better privacy against the whole network. So if you're doing something with your transaction, others won't— might not know about it until it's confirmed. And this makes it more difficult for the other side to start playing tricks that exploit some weird aspect of the mempool to cause problems for you.

Aaron van Wirdum Yeah, but I think that the main reason for this, if I'm understanding this correctly, is simply that presumably mining pools have more resources available to just store whatever transactions are sent to them. So we don't have to be as limited with the resources.

Sjors Provoost Yeah, I guess that's another argument, right?

Aaron van Wirdum And that's sort of how you solve the problem that we discussed when we started recording this podcast. Is that sort of the short way of…

Sjors Provoost I guess one way to put it is, yeah, there's a lot of these intricate rules about the mempool that are because it has to be somewhat small and careful with resources. And yeah, if you have giant resources, a 10 giga-[unclear] computer, then… you can have fewer subtle rules and therefore the whole system is a bit more predictable.

Aaron van Wirdum Yeah, miners have a clear financial incentive to actually have that. To actually have that sort of resources.

Sjors Provoost Yeah, because they're investing pretty heavily anyway. Especially a pool, right? Not even a single miner.

Aaron van Wirdum Yeah, and they want to earn the fees that will win if they set up these sorts of resources.

Sjors Provoost So, problems.

Aaron van Wirdum Problems. I want to point one… We're not going to follow the order of the thread, obviously, but one thing that's maybe important to notice at first is it's not an option actually as a user to send your transaction just to one miner and then have the miners shared with each other.

Sjors Provoost Yeah, that's right.

Aaron van Wirdum That's not incentive compatible because if you send it to one miner, that one miner will have an incentive to just keep that transaction for itself. So that miner… From now on, when we say miner, we mean mining pool, I think, in general. Assume that if we say miner, it's mining pool. Every individual miner pool will have an incentive to not share the transaction. They want to keep the transaction for themselves. So that way they will be the ones that mine it. So really you do need in this system to be able to send your transaction to all miners.

Sjors Provoost Yeah, because otherwise you have to wait forever. If you only send it to one miner and then, well, they'll only get a block of one… Let's say if the pool has 5% of the hash power, then... it's going to take 20 blocks for you to get confirmed statistically. And that's even assuming that your fee is high enough.

Aaron van Wirdum So then I think the next problem from there is how do you figure out who are all the miners and how to reach all of them, right?

Sjors Provoost Yeah, well, we could hire Vitalik again and he could make a list and say, these are the miners.

Aaron van Wirdum Why Vitalik?

Sjors Provoost Because we trust him.

Aaron van Wirdum Okay, fair enough.

Sjors Provoost And just to illustrate, that may not be an optimal solution. We'd rather not have a centralized list, obviously. And of course, the proposal didn't really go into that, but I'm pretty sure they would agree with that constraint. So then the question is, how would you go about...

Aaron van Wirdum Wait, what's the problem with the centralized list?

Sjors Provoost Well, somebody is in charge of it. So they can tell miners they have to pay a fee in order to join that list.

Aaron van Wirdum Yeah, or they can tell miners you're only getting on the list if you censor... these transactions.

Sjors Provoost Exactly. We've done another episode about mining pool censorship.

Aaron van Wirdum So having a centralized list is not an option because you basically completely defeat the point of Bitcoin itself if you have a centralized list.

Sjors Provoost So another option would be to just allow sort of a gossiping of these mining pools. So there's maybe a new peer-to-peer message and every node would tell every other node about every pool it knows about. Problem there is, how do you stop spam? Because I could spin up a node and broadcast a million different potential mining pools.

Aaron van Wirdum Yeah, this sounds a little bit like our previous episode. That's right. Where we indeed discussed how nodes right now gossip IP addresses of other Bitcoin nodes. And then they would do the same thing with addresses for miners. And as we discussed in the last episode, this system was actually being attacked. I spent essentially, well, it wasn't really a denial of service attack, but it was still a brutal attack as we discussed.

Sjors Provoost Yeah.

Aaron van Wirdum So this would open up that possibility if you have to gossip.

Sjors Provoost And the impact of an attack is much worse because if you're just talking about gossiping the address of peers, you only need to connect to one honest peer in order to get the right blockchain.

Aaron van Wirdum Right.

Sjors Provoost So the gossip doesn't have to be very good as long as you at least have one connection that actually leads you to an honest node, then you're fine. But not so with the mining pools, because as we just talked about, you really should be sending your transactions to every pool out there. So if there are a million potential pools being gossiped about, you have to essentially just try all a million of them, or at least you have to keep trying them until you think you have most of the hash power. Just aside from the question of how you would know that you have most of the hash power. So there has to be some limit on this gossip mechanism. And the question is, how would you do that limit? Well, there was a sub… So this mailing list thread…

Aaron van Wirdum But by limit, you mean not everyone should be able to publish any address. Yeah. Essentially, right?

Sjors Provoost But we also don't want the limit to be set by an authority. So there has to be some sort of neutral limit. Or there has to be some cost. And so Zmn, you know...

Aaron van Wirdum Zmn.

Sjors Provoost Zmn pronounced… Written Z-M-N-S-C-P-X-J. But he's fine with being called Zmn and with being called he. He said, well, we could have some sort of staking involved. And this is not proof of stake. So you don't have to have a stake in order to mine. But you would have to prove that you own some small amount of Bitcoin in order for your pool to be gossiped about. So it's just about being gossiped about. And then you can prioritize a little bit by who's staking enough coins. So that could work. It's more complicated, but it could work.

Aaron van Wirdum I feel a but coming.

Sjors Provoost Well, I mean, it's more complicated than what we have now, right? Right now everybody can be a miner and just listen in. Now they have to stake some coins and then some of the objections that were raised against that. One of them is that ideally you want miners to have very good privacy and so you want them to constantly stake different coins so that between different blocks you can't see that it's the same pool or miner that you're dealing with. But if they have to constantly stake new coins, well, that's expensive. So now they're incentivized to have the same identity over a long period of time. And that's not very good. On the other hand, as he points out, miners are really bad at privacy right now anyway because they're all revealing what pool they are. But they don't have to do that.

Aaron van Wirdum Yeah, and I think the argument is there because that was also, I think, in the OP, in the original email, is this idea that, you know, the way Bitcoin currently works or the current topography of the network, or at least, you know, the level of mining centralization means that in practice today, yeah, we only have 100 or whatever mining pools and they self-identify anyways. So some of these arguments don't necessarily hold up against the current state of Bitcoin. Like it's kind of similar. However… We're also designing Bitcoin for a potential future where mining really is banned worldwide, essentially. And that's where privacy becomes very important. And that's where a staking solution, like you mentioned just now, which potentially harms privacy, would therefore potentially harm mining privacy and therefore Bitcoin itself. I think that's a key thing to... take into account is that the way Bitcoin is being designed is not for today but for a potential worse tomorrow.

Sjors Provoost Yeah, of course also for today but… uh there's another problem with this system.

Aaron van Wirdum Well, you say that. Well, I don't I don't know if we want to go on a side quest on this particular topic but… Should we? I don't know. I'll just mention very briefly that I actually don't think Bitcoin is being optimized for today. That's one of Paul Sztorc's arguments for sidechains, for example, that while we live in an environment and in a world and in a regulatory environment where Bitcoin is actually just allowed and legal, then optimizing it for adversarial conditions gives it a disadvantage against systems that are not optimized for adversarial conditions because they can be more efficient and fast. And so you're sort of losing some competitive edge in that environment. But that's a…

Sjors Provoost Yeah, that makes sense I mean it depends on what what aspect of the protocol you're looking at right so there are already adversaries out there so lots of privacy improvements are already being made with the idea that there is there is there already are chain analysis of chain analytics companies out there, so

Aaron van Wirdum Yeah, that's true, but at least not really for mining apart from China I guess, and you know the solution there she just migrates from China, so we're really we're really sort of designing for a world where Bitcoin mining is banned everywhere, China everywhere, as Eric Voskuil actually literally explained it in the thread itself at some point.

Sjors Provoost You want to at least have that option to be able to exist in such a system. Yeah, exactly. So another downside here is that it's very tempting for wallets to say, well, I'm not going to send it to every miner out there, every new stake out there. I might look at the pie and only send to whatever represents 80% of the mining capacity. Because maybe with 20% of the connections, you'll get your transaction to 80% of the miners. And that creates a problem for new miners.

Aaron van Wirdum The reason for that is essentially because it's just a hassle to go and look for all of these small pools. It's much easier to just say, all right, if I get it to these 10 or these five, then it's 90% of hash power and it will almost certainly confirm.

Sjors Provoost Yeah, and the wallet software is probably not going to do all this verification. It's probably going to be the wallet authors that put in a list, a hard-coded list of common miners for common pools. So that's a problem. And as Sipa Pieter Wuille pointed out, new pools could also be censored. So if you're trying to announce a new pool by staking some coins, then the existing miners could try to make sure that you never get to stake your coins. So there's also a risk there too, that it becomes a [unclear].

Aaron van Wirdum Right, yeah, that was an interesting argument. But let's take a small step back to the previous one. What was the previous one?

Sjors Provoost That basically… wallets have an incentive to only pick a subset of the pools. And so if you're starting a new pool, you're probably very small. So nobody's going to send you any transactions.

Aaron van Wirdum Right, exactly. So if wallets, out of convenience, prioritize the bigger pools, then it sort of locks these bigger pools in place and it becomes much harder to compete with these pools, which is bad for, again, decentralization, for example, because these big pools can be regulated more easily. If competition is more difficult then you you know it becomes harder to find your way out of such a centralized solution and then the one after that— see, my my memory is the worst what was the one that you said after that?

Sjors Provoost Uh, censorship by other miners

Aaron van Wirdum Oh, yeah yeah, so yeah so… So Zmn was going on this sort of thought experiment. Let's assume that we really want to do this. Then what are the ways to do that? And then one of the ways which we just described is to use staking as an anti-denial service type of solution. But then you need… the existing miners to allow the stake to be confirmed on the blockchain which they have an incentive not to do of course because that's also a way to keep the competition out. So yeah that was that was an interesting…

Sjors Provoost And I'm sure you could continue that conversation to come up with a system that prevents even that censorship etc., but you know it's it's still a can of worms that you're opening and you know we're this whole proposal serves to close one can of worms but as we're starting to discover now the proposal is opening another several other cans of worms. So the net number of worms might actually go up if we do this.

Aaron van Wirdum I prefer less worms. But I think we're going to see even more worms or not?

Sjors Provoost Yes. So one of the arguments that was used to advocate this proposal was bandwidth. And it may be good to point out that in reality what happens is there's a lot of bandwidth to sort of gossip about which transactions exist, which is done using short identifiers. But the actual transactions themselves are usually only sent once. So your node gets a bunch of IDs and it's like, okay, give me the transactions that I don't know yet. And so that only happens once. And then…

Aaron van Wirdum These are like recent improvements or…

Sjors Provoost Yeah, I don't know what recent means for multiple years, but…

Aaron van Wirdum Well, at least it wasn't there from the start.

Sjors Provoost Yeah.

Aaron van Wirdum Optimizations and also some optimizations moving ahead because it used to be the case indeed that every transaction was sent over the whole network and then a block was found and then the block full of all of these transactions was sent over the network as well.

Sjors Provoost Well, that's the second part of this. So the transactions themselves are only sent once. but also indeed every block is sent without the transactions in it. At least if you're using this, your node will probably do that using this compact block idea where the compact block just says, here's the header of the block and here's the list of transactions that are in the block. You already have these transactions, so you can construct a block locally. You don't have to get them from me. And if you are missing any of the transactions, just ask. And in practice, that means the blocks are propagated really, really quickly.

Aaron van Wirdum Yeah. So there's two benefits. It costs less bandwidth, which is a resource, and therefore it doesn't, it costs less resource, which is a benefit. And it transmits over the network faster, which again also helps against… pool centralization, which is another topic, which I think we probably shouldn't get into that.

Sjors Provoost And basically, it's important to have very few orphans or stale blocks where if the block is still propagating around, then somebody else might also find a block at the same height. And that just increases the opportunity for double spends and it causes lost revenue for those miners. So it means it's better to be a big miner, et cetera. Now, if you want to talk about…

Aaron van Wirdum Fast transmission is better.

Sjors Provoost Yeah, if you want to talk about block propagation in general, look how to get blocks across the network fast. There is a really good talk by Greg Maxwell from 2017 at the San Francisco Bitcoin Developer Meetup where he talks, it's called advances in block propagation.

Aaron van Wirdum I thought you were going to just, from the top of your head, mention another Bitcoin Explained episode.

Sjors Provoost No, we could probably do a Bitcoin Explained episode except that I would have to do like five weeks of reading just to catch up with everything he said in that one hour and then it's, you know, four years ago. So who knows? So anyway, so the bandwidth argument is not as strong because it turns out there's already a lot of deduplications and we've talked about one episode about how to do mempool even more efficient. I forgot the name of it.

Aaron van Wirdum Oh, yeah. Oh, I forgot. Oh, so you don't have a perfect memory. Yeah, I forgot as well.

Sjors Provoost I told you I don't have a perfect memory. Anyway, so that was mentioned too. So the bandwidth argument is not as strong. Plus, if bandwidth is a constraint for you, just don't relay transactions because you're free to turn the mempool off on your own node. So I think the main argument for the proposal was complexity, not bandwidth. But the bandwidth argument was not very strong.

Aaron van Wirdum Is there more? I'm sure there's… This is the point where it starts feeling like the exam that I mentioned earlier. Let's see how much of the thread we can remember.

Sjors Provoost Well, that's why I have notes. So there was a really nice... There's a couple of nice one-liners in this whole thread, but I'll cite one by sipa. And this is about... Normally, everybody can see what's happening in a mempool, right? But in this proposal, there is no mempool, and only select miners can see what's going on. And so he would say, “Replacing socialized transparency with a few who get to see the actual details.” That actually doesn't sound as good as it is. But basically, yeah, you're you know, everybody can see— normally everybody can see what's going on, and now you can't see it. So, you know you don't know whether there's any complexity but there might be all sorts of mining shenanigans going on you don't know if pools are colluding or not or you know they have one view of the network you have a different view of the network so

Aaron van Wirdum you would prefer that everyone can just see what's going on with the mempool and the blocks rather than just a select group of miners. yeah exactly,

Sjors Provoost Yeah, so a couple of things that were already also mentioned in the paper. There are proposals like BetterHash and P2Pool, which are ways to get more mining pools or even to solo mine. But those proposals, you know, if everybody is solo mining or if mining pools get super, super small, that doesn't really work well with this, what we just discussed. Because then the list of places where you'd have to send your transactions would be quite large.

Aaron van Wirdum Oh, I have another one. The fee estimation becomes harder because right now fee estimation actually takes the mempool into account to determine how much fee a node will include in the next transaction that it creates. If I'm going to be paying you, then my node will essentially look at the mempool as well as past block. If my node doesn't have a mempool, then I can't use that for fee estimation and therefore I might be overpaying in fees or waiting too long before my transaction finally confirms.

Sjors Provoost Because the mempool makes it more difficult for miners to sort of cheat when it comes to fees. So what a miner could do is if they just compose the block themselves, they could put a bunch of transactions inside the block that pay really high fees. But it's just money moving from themselves to themselves and the fee also goes to themselves. So then it looks like the fee is really high. But given that the mempool exists, if you do something like that, if you broadcast a transaction like that, it will get mined by your competitors. So it's a transaction from you to yourself, but the fee goes to your competitors. So it's very expensive to lie about the fees.

Aaron van Wirdum In general, of course, one of the things that was mentioned, and we already mentioned a form of it at least, which was sort of that your wallet might not have the incentive to look for smaller pools. The same is true even if your wallet does have the incentive or even if you do try, then even then there's going to be new miners joining the network and a very new miner might not be included in the list yet. There's a delay between... joining the network and getting accepted by letting people know that you're accepting transactions while right now on Bitcoin you just plug in and be ready from the get-go.

Sjors Provoost Well, we already talked about centralization in general, right? And as a reminder, why centralization could be bad. If there's just 50 pools or 10 pools, that creates very clear denial of service targets. So DDoS targets, like who, you know, if an attacker wants to take out certain nodes using any of the attacks we've previously talked about, well, they know which nodes to focus their attack on. Whereas right now, if you look at the network, at least naively, any node could be a miner. So you have no idea which Bitcoin node to attack to actually bother a miner. So it's kind of nice that miners can hide out in the crowd in general.

Aaron van Wirdum Yeah, you kind of want every node to look the same. You want every node to look like a peer on the network. And then some of these peers might be mining. And there are ways to de-anonymize that already. That was also mentioned in the thread. You can sort of analyze to see where new blocks emerge on the network and then that's presumably miners. But it's

Sjors Provoost still a bit probabilistic because you're not listening to all nodes at the same time and there's some tricks in it.

Aaron van Wirdum And I'm sure we can think of future optimizations to decrease that problem as well. Dandelion, that kind of stuff, you can maybe do that for blocks. That's a tangent.

Sjors Provoost So I can bring up one more little tangent that was brought up that was interesting from this discussion. That's not really an upside or a downside.

Aaron van Wirdum Is this the MISC part of the podcast?

Sjors Provoost Yeah, but it's the subset of the MISC part of the podcast. And this is that right now nodes, they have some interest. For the most part, you're relaying altruistically, but there is some self-interest, right? There is a self-interest of being able to calculate fees, for example. There's a self-interest of making sure blocks are propagated fast because that makes it less likely that your confirmations get cancelled. So that's all good. But it would be nice if there was a more direct way to make money from being a relayer. And what Zmn proposes roughly is that each node could try and compose packages of transactions, look at the mempool and basically construct packages that are economically efficient. Because it's actually mathematically quite a hard problem to make the most optimal block given a set of transactions. If you have 300 megabytes of transactions, to actually select them in a way that you maximize your revenue. And so you could outsource that computational difficulty task to individual nodes, and they would send you package proposals. And in exchange for a good proposal, you would get paid. Now, this is very hand-wavy. Because there's all sorts of things like how would you actually do this? But it was a cool idea.

Aaron van Wirdum I lost the plot on that one. Hopefully the listeners did not.

Sjors Provoost That's okay if you did. Yeah, I think that's roughly the whole discussion that we did. So you should give it a read.

Aaron van Wirdum Yeah, I hope we passed our exam. I hope our listeners paid attention for when they get the exam. We probably forgot some things. If you're really interested in this stuff, obviously check out the thread itself. It kept going for a while and there were some surprisingly interesting insights. Some I hope we conveyed, but we probably forgot at least one or two.

Sjors Provoost All right. So you got anything else then?

Aaron van Wirdum No, I'll see you in, I guess, a month from now or something like that.

Sjors Provoost Who knows? Thank you for listening to Bitcoin Explained.