WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:19.790 --> 00:00:24.390 Live from Utrecht, this is Bitcoin Explained. Hello. Hey, Sjors. 00:00:24.730 --> 00:00:25.390 What's up? 00:00:25.970 --> 00:00:26.950 I'm doing well. 00:00:29.210 --> 00:00:33.710 We're still in Utrecht, as I just said, but only for a couple more days. I'm on 00:00:33.710 --> 00:00:38.050 my way back to El Salvador, essentially, for a couple of conferences. And I think 00:00:38.050 --> 00:00:39.490 you're going to be traveling as well. 00:00:40.150 --> 00:00:41.650 Hopefully, if it's warmer. 00:00:42.890 --> 00:00:45.030 And if the COVID situation allows it. 00:00:45.450 --> 00:00:47.930 Well, wherever the COVID situation allows it. 00:00:48.270 --> 00:00:53.230 So anyways, the reason I mentioned that is because we are recording this episode 00:00:53.230 --> 00:00:58.280 probably… We're recording this episode ahead of time. We're recording this 00:00:58.280 --> 00:01:02.640 episode probably at least two weeks before it's actually published. And we're 00:01:02.640 --> 00:01:08.400 going to discuss a thread from the Bitcoin development mailing list that 00:01:08.400 --> 00:01:10.920 was published a couple weeks ago. 00:01:11.200 --> 00:01:11.840 That's right. 00:01:12.020 --> 00:01:15.260 So by the time people are listening to this, they are going to be hearing a 00:01:15.260 --> 00:01:18.060 discussion on a thread that's at least a month old. 00:01:18.380 --> 00:01:22.120 But it's good. You need to be reminded occasionally of the things that are 00:01:22.120 --> 00:01:25.580 important. And besides, last episode, I think we talked about something from 00:01:25.580 --> 00:01:26.240 three months ago. 00:01:28.470 --> 00:01:33.570 Yeah, if you want fresh content, Bitcoin Explained is not a place for you. But if 00:01:33.570 --> 00:01:38.690 you want exciting and interesting content 00:01:38.690 --> 00:01:44.570 and… from the top expert in the space, Sjors Provoost, then Bitcoin Explained is perfect. 00:01:44.850 --> 00:01:47.950 If you want it translated by the top journalist in the space, then Bitcoin 00:01:47.950 --> 00:01:49.090 Explained is also perfect. 00:01:48.810 --> 00:01:53.370 Stop it. All right, Sjors, enough about that. Let's get to the point. We are 00:01:53.370 --> 00:01:56.890 going to be discussing a thread. Do you have a name of the thread in front of you? 00:01:56.910 --> 00:02:00.650 That's right. It's called Death to the mempool, Long Live the mempool. 00:02:00.950 --> 00:02:06.780 Right. It's a proposal to basically abolish the mempool, right? 00:02:07.400 --> 00:02:10.700 So let's get... Who started the thread? 00:02:11.950 --> 00:02:16.160 niftynei. He's a— she's a C-Lightning developer. 00:02:16.640 --> 00:02:16.980 Yeah. 00:02:17.740 --> 00:02:23.060 Blockstream. Now, we don't really know whether this proposal is super serious or 00:02:23.060 --> 00:02:27.820 more of a thought exercise, but it resulted in a very interesting discussion. 00:02:28.380 --> 00:02:32.940 Right, yeah, when I first when I saw the thread it felt a little bit like 00:02:32.940 --> 00:02:38.120 homework; it felt a little bit like you're making like an exam where the teacher 00:02:38.120 --> 00:02:44.010 says all right, why don't we redesign Bitcoin to get rid of the mempool? 00:02:44.250 --> 00:02:48.490 And we'll explain what the exact proposal is. And then you as the students have 00:02:48.490 --> 00:02:53.470 to sort of figure out why that's not a good idea. That was sort of my first 00:02:53.470 --> 00:02:55.450 reading. That's sort of what it did with my brain. 00:02:55.630 --> 00:03:00.250 Yeah, and it helps to remind you why this mempool is useful in the first place. 00:03:00.530 --> 00:03:05.030 Right, exactly. The interesting thing for me was, you know, I... 00:03:06.130 --> 00:03:11.210 I could figure out, you know, one or two reasons why I didn't, you know, like the 00:03:11.210 --> 00:03:15.450 proposal, but then the threads kept going for a while with more reasons and 00:03:15.510 --> 00:03:20.650 counter-arguments, and it became more interesting than I sort of anticipated at 00:03:20.650 --> 00:03:21.670 first, I would say. 00:03:21.890 --> 00:03:26.970 Yeah, and then also lots of semi-related interesting proposals, for example, by 00:03:26.970 --> 00:03:31.010 Zmn, Z-M-N-S-C-P-X-J, the pseudonymous. 00:03:31.310 --> 00:03:33.450 Okay, so let's just get into it. 00:03:33.630 --> 00:03:33.770 Yep. 00:03:34.310 --> 00:03:35.290 First question. 00:03:36.780 --> 00:03:37.900 What is a mempool? 00:03:38.920 --> 00:03:44.800 So the mempool, we talked about the mempool at least in episodes 19, 26, and 38. 00:03:45.120 --> 00:03:48.900 I don't know if you want to listen to those. The mempool is a place where… 00:03:48.900 --> 00:03:53.120 It's incredible how you remember all of our episodes just from the top of your head. 00:03:53.180 --> 00:03:53.600 Absolutely. 00:03:53.800 --> 00:03:56.420 That's how a wizard's brain works. 00:03:56.810 --> 00:04:02.390 So basically, well, transactions go into blocks, but before they go into blocks, 00:04:02.390 --> 00:04:07.050 they have to be proposed somehow. And the way people propose transactions is just 00:04:07.050 --> 00:04:11.950 to send them to everybody and everyone. And then every node has a list of 00:04:11.950 --> 00:04:15.930 transactions that are not yet in a block, probably about 300 megabytes worth of 00:04:15.930 --> 00:04:19.830 those, depending on the mempool weather, as people would call it. 00:04:21.340 --> 00:04:26.120 And this is generally kept in memory, though, as Eric Voskuil pointed out in the 00:04:26.120 --> 00:04:29.680 mailing list, it doesn't have to be done in memory. His Bitcoin client, 00:04:29.780 --> 00:04:34.340 Libbitcoin, keeps it all on disk. It doesn't really matter. I mean, the way he 00:04:34.340 --> 00:04:34.940 would describe it… 00:04:34.940 --> 00:04:36.180 You could probably store it in your memory. 00:04:36.880 --> 00:04:38.780 No, I have actually quite a bad memory. 00:04:38.780 --> 00:04:42.780 No, no, we've noticed, Sjors, your memory is... Anyways, go on. 00:04:43.100 --> 00:04:47.500 So basically, I mean, what he would say is you can, all these transactions that 00:04:47.500 --> 00:04:51.080 are proposed transactions, you can just put them on a disk and then you can say, 00:04:51.340 --> 00:04:55.740 okay, here's a block and the block points to all these transactions now. That's 00:04:55.740 --> 00:04:59.820 essentially what a block is. Just points to all these transactions and then you're done. 00:05:01.120 --> 00:05:03.980 So yeah, I guess that's the mempool. 00:05:05.050 --> 00:05:09.750 Yeah, that last part about how Libbitcoin works was a little bit of a sidestep. 00:05:09.870 --> 00:05:14.350 But in general, the mempool is just a collection of transactions that nodes keep 00:05:14.350 --> 00:05:18.310 and that miners, well, keep and forward to other nodes, just the nodes that are 00:05:18.310 --> 00:05:23.450 sort of propagated over the network. And then miners use their, every node has 00:05:23.450 --> 00:05:27.090 its own mempool. And then the miners use their mempool to select transactions, 00:05:27.090 --> 00:05:30.490 which they're going to mine on and hopefully become the new block. 00:05:30.810 --> 00:05:35.600 Yeah. But in general, most of the transactions that are in your mempool will 00:05:35.600 --> 00:05:39.180 eventually be in a block, and that's kind of important for the discussion ahead. 00:05:40.430 --> 00:05:42.050 So what is the problem? 00:05:42.770 --> 00:05:43.910 Well, there's many problems. 00:05:43.910 --> 00:05:49.290 What is the problem that this mailing list thread seeked to address and wanted to solve? 00:05:50.350 --> 00:05:56.330 Well, one problem is bandwidth. So at least as it was explained, like sending all 00:05:56.330 --> 00:06:00.030 these transactions around all the time to all your peers uses up quite a bit of 00:06:00.030 --> 00:06:05.620 bandwidth. And the second is that, and that's I think what we covered in episode 00:06:05.620 --> 00:06:10.860 38, we discussed then there was a bug in Bitcoin Core with 00:06:10.860 --> 00:06:16.420 how the way RBF replaced by fee was implemented. And then we tried to explain how 00:06:16.420 --> 00:06:22.180 that impacted Lightning in unpleasant ways. And we failed to explain how that 00:06:22.180 --> 00:06:26.760 impacted Lightning because it is very complicated. And this complexity is the 00:06:26.760 --> 00:06:30.820 problem. So it is very difficult for people, especially working on things like 00:06:30.820 --> 00:06:35.980 Lightning, to make the protocol safe against all the little gotchas that exist in 00:06:35.980 --> 00:06:40.220 this mempool. The mempool looks very simple as we just described it, but there's 00:06:40.220 --> 00:06:44.750 lots of intricate details that you really have to understand. And if you don't 00:06:44.750 --> 00:06:49.170 understand those correctly, then what could happen is you try to broadcast a 00:06:49.170 --> 00:06:53.370 transaction, for example, to take money back from your channel because somebody 00:06:53.370 --> 00:06:58.410 cheated on you on the channel. And then that other person can do some shenanigan, 00:06:58.610 --> 00:07:01.770 put some other transaction in the mempool or lots of transactions in the mempool. 00:07:01.770 --> 00:07:07.670 And all of a sudden, your transaction never gets confirmed and theirs does. And 00:07:07.670 --> 00:07:12.290 this is very difficult to reason about. And so that's why the suggestion was, why 00:07:12.290 --> 00:07:13.770 don't we just get rid of the mempool? 00:07:14.620 --> 00:07:19.580 Yeah, I think the heart of the problem, which you just explained, is that… 00:07:21.610 --> 00:07:25.510 Sometimes it's important that your transaction actually makes it in the mempool 00:07:25.510 --> 00:07:31.470 at least but there are restrictions on how big everyone's mempool can be 00:07:31.470 --> 00:07:35.490 because everyone has to do that and that just requires resources so there's a cap 00:07:35.490 --> 00:07:39.310 on that but because of that cap, that means your transaction can't always get in, 00:07:39.310 --> 00:07:43.430 and that opens the door to niche types of attacks, and we're not going to get 00:07:43.430 --> 00:07:44.630 into that in detail but… 00:07:45.150 --> 00:07:50.190 Yeah, and it's worse than just having a cap on the size of the mempool. There's 00:07:50.190 --> 00:07:54.950 all sorts of rules. Like if 100 transactions are related to each other and you 00:07:54.950 --> 00:07:58.850 want to replace one of those 100 transactions, then that can cause problems too. 00:08:00.370 --> 00:08:05.830 There are a number of limitations that sort of ensure that nodes don't get 00:08:05.830 --> 00:08:10.930 overloaded, but these limitations then open the door to potential weaknesses or 00:08:10.930 --> 00:08:12.850 attacks. That's a very short version. 00:08:12.950 --> 00:08:16.010 And this is also, of course, an incentive problem, really because the incentive 00:08:16.010 --> 00:08:20.010 for things like Lightning is to you know be secure for the users of the Lightning 00:08:20.010 --> 00:08:23.890 channels but the incentives for the people running a node, well they're just 00:08:23.890 --> 00:08:29.130 having that mempool there partially altruistically they have slightly different 00:08:29.130 --> 00:08:32.830 incentives. They don't want to get overloaded, but their incentive is not to 00:08:32.830 --> 00:08:36.290 protect the Lightning network and this [unclear]— this can cause some friction 00:08:36.290 --> 00:08:38.210 because the incentives are slightly different. 00:08:38.530 --> 00:08:43.730 Okay, so what we've now— we've now explained 00:08:44.900 --> 00:08:50.730 in our great podcast, Bitcoin Explained, what the mempool is and what the issues 00:08:50.730 --> 00:08:56.230 with it are in some circumstances. And then this thread offered a 00:08:56.230 --> 00:08:59.090 solution. So what was the solution that was proposed? 00:08:59.330 --> 00:09:00.330 Well, get rid of the mempool. 00:09:00.510 --> 00:09:02.190 Get rid of the mempool altogether. 00:09:02.710 --> 00:09:08.470 Yeah. And of course, that immediately poses a question. If I have a transaction 00:09:08.470 --> 00:09:13.320 and I wanted to get it in a block, but there is no mempool, well, then what do I 00:09:13.320 --> 00:09:15.540 do? Do I just scream on the streets? 00:09:16.220 --> 00:09:19.880 I mean, in a way, that's actually how it works now. You're just screaming it to 00:09:19.880 --> 00:09:20.440 the network. 00:09:21.000 --> 00:09:22.240 Yeah, that's correct. 00:09:23.190 --> 00:09:28.230 Screaming to the streets is probably not an upgrade, but they proposed, 00:09:28.430 --> 00:09:32.630 why not just send your transaction directly to a miner? 00:09:32.850 --> 00:09:33.250 Exactly. 00:09:33.630 --> 00:09:37.430 Because miners, that's the one that actually needs the transactions. They're the 00:09:37.430 --> 00:09:41.370 main one. In a way, the only ones, but definitely the main ones that need a 00:09:41.370 --> 00:09:45.490 transaction because they're the ones creating blocks. So why don't we create a 00:09:45.490 --> 00:09:48.150 system where we send the transactions directly to miners, right? 00:09:48.490 --> 00:09:53.630 Yeah. And of course, that brings the question of, well, probably to a mining 00:09:53.630 --> 00:09:58.410 pool, not to an individual miner. But still the question then is, well, who are 00:09:58.410 --> 00:10:00.090 the miners? How many are there? 00:10:00.270 --> 00:10:01.310 Where do you send the transactions? 00:10:01.730 --> 00:10:07.470 Where are they? Yeah. And do we want to send it to their home address by 00:10:07.470 --> 00:10:12.080 envelope? Or how are we going to do that? And so the proposal there was to say, 00:10:12.160 --> 00:10:17.660 well, we want to preserve miner anonymity. That was still a goal. 00:10:18.470 --> 00:10:23.790 And the way it could be done is miners could publish an onion service, so a Tor 00:10:23.790 --> 00:10:28.610 service, a hidden service, like a dark website, I guess. And to this dark 00:10:28.610 --> 00:10:33.250 website, quote-unquote, you send your transaction. Automatically, of course, your 00:10:33.250 --> 00:10:37.210 wallet might have a list of 100 different miners, and it would just send the 00:10:37.210 --> 00:10:40.610 transaction to all 100 of them. That would be the idea. 00:10:41.290 --> 00:10:46.590 Yeah, so if you're a miner, or maybe we should say more specifically, actually, 00:10:46.830 --> 00:10:50.690 if you're a mining pool, because that's sort of the point, that a lot of the 00:10:50.690 --> 00:10:56.130 transactions— a lot of the blocks, all of the blocks, essentially, I think, are 00:10:56.130 --> 00:11:00.520 currently mined by mining pools. And as long as 00:11:00.520 --> 00:11:06.500 there's a manageable number of mining pools, then you can 00:11:06.500 --> 00:11:09.040 get all of their addresses and send it to them directly. 00:11:09.660 --> 00:11:12.000 Yeah, that's the proposal. 00:11:12.360 --> 00:11:17.270 When I say addresses, like you mentioned, it's like a Tor address. Yeah, like a 00:11:17.270 --> 00:11:18.370 hidden service. 00:11:18.690 --> 00:11:22.190 So this poses a problem, or a number of problems. 00:11:23.190 --> 00:11:28.830 Are we ready to get into the problems? This was the proposal, right? I think we 00:11:28.830 --> 00:11:32.890 captured the essence of the proposal. Rather than having a mempool, rather than 00:11:32.890 --> 00:11:38.700 having every node on the network transmit every transaction to everyone 00:11:38.700 --> 00:11:42.620 else, to every other node, rather, you know, as a user sending your transaction 00:11:42.620 --> 00:11:48.280 just to the Bitcoin network, instead, you'll send them to a number of mining pools. 00:11:48.520 --> 00:11:52.240 Yeah, and one thing you can do there also is you can have, since you have a 00:11:52.240 --> 00:11:56.180 communication channel with the miner anyway, you can ask what fees they want, you 00:11:56.180 --> 00:12:00.260 know, rather than guessing. That could be an advantage or not, but that's another 00:12:00.260 --> 00:12:00.760 possibility. 00:12:02.230 --> 00:12:05.270 So this gives you a little bit better. I mean, the reason why this might be 00:12:05.270 --> 00:12:09.560 useful is it gives you better privacy against the whole network. So if you're 00:12:09.560 --> 00:12:14.400 doing something with your transaction, others won't— might not know about it 00:12:14.400 --> 00:12:18.200 until it's confirmed. And this makes it more difficult for the other side to 00:12:18.200 --> 00:12:23.080 start playing tricks that exploit some weird aspect of the mempool to cause 00:12:23.080 --> 00:12:23.720 problems for you. 00:12:23.980 --> 00:12:27.360 Yeah, but I think that the main reason for this, if I'm understanding this 00:12:27.360 --> 00:12:32.940 correctly, is simply that presumably mining pools have more resources available 00:12:32.940 --> 00:12:38.730 to just store whatever transactions are sent to them. So we don't have to be 00:12:38.730 --> 00:12:41.130 as limited with the resources. 00:12:41.670 --> 00:12:43.610 Yeah, I guess that's another argument, right? 00:12:43.610 --> 00:12:46.490 And that's sort of how you solve the problem that we discussed when we started 00:12:46.490 --> 00:12:49.490 recording this podcast. Is that sort of the short way of… 00:12:49.490 --> 00:12:52.970 I guess one way to put it is, yeah, there's a lot of these intricate rules about 00:12:52.970 --> 00:12:58.710 the mempool that are because it has to be somewhat small and careful 00:12:58.710 --> 00:13:03.310 with resources. And yeah, if you have giant resources, a 10 giga-[unclear] 00:13:03.310 --> 00:13:07.930 computer, then… you can have fewer subtle rules and therefore the whole system is 00:13:07.930 --> 00:13:08.590 a bit more predictable. 00:13:08.870 --> 00:13:12.790 Yeah, miners have a clear financial incentive to actually have that. To actually 00:13:12.790 --> 00:13:14.550 have that sort of resources. 00:13:14.810 --> 00:13:18.070 Yeah, because they're investing pretty heavily anyway. Especially a pool, right? 00:13:18.190 --> 00:13:19.250 Not even a single miner. 00:13:19.490 --> 00:13:25.740 Yeah, and they want to earn the fees that will win if they set up these sorts of resources. 00:13:26.240 --> 00:13:27.100 So, problems. 00:13:28.370 --> 00:13:31.010 Problems. I want to point one… 00:13:32.590 --> 00:13:35.990 We're not going to follow the order of the thread, obviously, but one thing 00:13:35.990 --> 00:13:41.990 that's maybe important to notice at first is it's not an option 00:13:41.990 --> 00:13:46.510 actually as a user to send your transaction just to one miner and then have the 00:13:46.510 --> 00:13:48.090 miners shared with each other. 00:13:48.350 --> 00:13:49.010 Yeah, that's right. 00:13:49.190 --> 00:13:53.170 That's not incentive compatible because if you send it to one miner, that one 00:13:53.170 --> 00:13:56.910 miner will have an incentive to just keep that transaction for itself. So that 00:13:56.910 --> 00:14:01.850 miner… From now on, when we say miner, we mean mining pool, I think, in general. 00:14:02.330 --> 00:14:06.270 Assume that if we say miner, it's mining pool. Every individual miner pool will 00:14:06.270 --> 00:14:09.690 have an incentive to not share the transaction. They want to keep the transaction 00:14:09.690 --> 00:14:15.170 for themselves. So that way they will be the ones that mine it. So really you do 00:14:15.170 --> 00:14:19.710 need in this system to be able to send your transaction to all miners. 00:14:20.050 --> 00:14:23.410 Yeah, because otherwise you have to wait forever. If you only send it to one 00:14:23.410 --> 00:14:27.290 miner and then, well, they'll only get a block of one… Let's say if the pool has 00:14:27.290 --> 00:14:31.460 5% of the hash power, then... it's going to take 20 blocks for you to get 00:14:31.460 --> 00:14:34.740 confirmed statistically. And that's even assuming that your fee is high enough. 00:14:35.910 --> 00:14:41.070 So then I think the next problem from there is how do you figure out who are all 00:14:41.070 --> 00:14:43.190 the miners and how to reach all of them, right? 00:14:43.370 --> 00:14:47.410 Yeah, well, we could hire Vitalik again and he could make a list and say, these 00:14:47.410 --> 00:14:47.910 are the miners. 00:14:48.550 --> 00:14:49.310 Why Vitalik? 00:14:49.790 --> 00:14:50.870 Because we trust him. 00:14:51.130 --> 00:14:51.950 Okay, fair enough. 00:14:52.230 --> 00:14:55.750 And just to illustrate, that may not be an optimal solution. 00:14:57.360 --> 00:15:02.800 We'd rather not have a centralized list, obviously. And of course, the proposal 00:15:02.800 --> 00:15:06.600 didn't really go into that, but I'm pretty sure they would agree with that 00:15:06.600 --> 00:15:10.460 constraint. So then the question is, how would you go about... 00:15:10.460 --> 00:15:12.280 Wait, what's the problem with the centralized list? 00:15:12.680 --> 00:15:17.600 Well, somebody is in charge of it. So they can tell miners they have to pay a fee 00:15:17.600 --> 00:15:18.920 in order to join that list. 00:15:19.680 --> 00:15:23.860 Yeah, or they can tell miners you're only getting on the list if you censor... 00:15:24.210 --> 00:15:25.230 these transactions. 00:15:25.590 --> 00:15:28.590 Exactly. We've done another episode about mining pool censorship. 00:15:29.450 --> 00:15:34.510 So having a centralized list is not an option because you basically completely 00:15:34.510 --> 00:15:39.190 defeat the point of Bitcoin itself if you have a centralized list. 00:15:39.370 --> 00:15:44.910 So another option would be to just allow sort of a gossiping of these 00:15:44.910 --> 00:15:50.730 mining pools. So there's maybe a new peer-to-peer message and every node would 00:15:50.730 --> 00:15:55.860 tell every other node about every pool it knows about. Problem there is, how do 00:15:55.860 --> 00:16:01.160 you stop spam? Because I could spin up a node and broadcast a million different 00:16:01.160 --> 00:16:02.640 potential mining pools. 00:16:02.880 --> 00:16:07.620 Yeah, this sounds a little bit like our previous episode. That's right. Where we 00:16:07.620 --> 00:16:13.540 indeed discussed how nodes right now gossip IP addresses of 00:16:13.540 --> 00:16:17.560 other Bitcoin nodes. And then they would do the same thing with addresses for 00:16:17.560 --> 00:16:22.640 miners. And as we discussed in the last episode, this system was actually being 00:16:22.640 --> 00:16:28.270 attacked. I spent essentially, well, it wasn't really a denial of service attack, 00:16:28.430 --> 00:16:31.970 but it was still a brutal attack as we discussed. 00:16:32.290 --> 00:16:32.470 Yeah. 00:16:32.690 --> 00:16:35.690 So this would open up that possibility if you have to gossip. 00:16:35.990 --> 00:16:39.990 And the impact of an attack is much worse because if you're just talking about 00:16:39.990 --> 00:16:45.310 gossiping the address of peers, you only need to connect to one honest peer in 00:16:45.310 --> 00:16:46.450 order to get the right blockchain. 00:16:47.010 --> 00:16:47.490 Right. 00:16:48.570 --> 00:16:51.970 So the gossip doesn't have to be very good as long as you at least have one 00:16:51.970 --> 00:16:56.370 connection that actually leads you to an honest node, then you're fine. But not 00:16:56.370 --> 00:16:59.390 so with the mining pools, because as we just talked about, you really should be 00:16:59.390 --> 00:17:03.590 sending your transactions to every pool out there. So if there are a million 00:17:03.590 --> 00:17:08.210 potential pools being gossiped about, you have to essentially just try all a 00:17:08.210 --> 00:17:12.270 million of them, or at least you have to keep trying them until you think you 00:17:12.270 --> 00:17:16.520 have most of the hash power. Just aside from the question of how you would know 00:17:16.520 --> 00:17:18.200 that you have most of the hash power. 00:17:19.710 --> 00:17:25.610 So there has to be some limit on this gossip mechanism. And 00:17:25.610 --> 00:17:30.640 the question is, how would you do that limit? Well, there was a sub… So this 00:17:30.640 --> 00:17:31.660 mailing list thread… 00:17:31.660 --> 00:17:35.660 But by limit, you mean not everyone should be able to publish any address. Yeah. 00:17:35.660 --> 00:17:36.500 Essentially, right? 00:17:36.600 --> 00:17:39.620 But we also don't want the limit to be set by an authority. So there has to be 00:17:39.620 --> 00:17:45.560 some sort of neutral limit. Or there has to be some cost. And so Zmn, you know... 00:17:45.560 --> 00:17:45.800 Zmn. 00:17:46.080 --> 00:17:51.800 Zmn pronounced… Written Z-M-N-S-C-P-X-J. But 00:17:51.800 --> 00:17:55.160 he's fine with being called Zmn and with being called he. 00:17:56.920 --> 00:18:01.480 He said, well, we could have some sort of staking involved. And this is not proof 00:18:01.480 --> 00:18:06.680 of stake. So you don't have to have a stake in order to mine. But you would have 00:18:06.680 --> 00:18:12.620 to prove that you own some small amount of Bitcoin in order for your pool to be 00:18:12.620 --> 00:18:16.340 gossiped about. So it's just about being gossiped about. And then you can 00:18:16.340 --> 00:18:22.120 prioritize a little bit by who's staking enough coins. So that could work. 00:18:22.120 --> 00:18:23.600 It's more complicated, but it could work. 00:18:25.990 --> 00:18:27.490 I feel a but coming. 00:18:29.610 --> 00:18:33.690 Well, I mean, it's more complicated than what we have now, right? Right now 00:18:33.690 --> 00:18:39.370 everybody can be a miner and just listen in. Now they have to stake some coins 00:18:39.370 --> 00:18:43.670 and then some of the objections that were raised against that. One of them is 00:18:43.670 --> 00:18:48.990 that ideally you want miners to have very good privacy and so you want them to 00:18:48.990 --> 00:18:52.890 constantly stake different coins so that between different blocks you can't see 00:18:52.890 --> 00:18:56.680 that it's the same pool or miner that you're dealing with. But if they have to 00:18:56.680 --> 00:19:00.600 constantly stake new coins, well, that's expensive. So now they're incentivized 00:19:00.600 --> 00:19:05.140 to have the same identity over a long period of time. And that's not very good. 00:19:05.520 --> 00:19:07.500 On the other hand, as he points out, 00:19:08.800 --> 00:19:12.060 miners are really bad at privacy right now anyway because they're all revealing 00:19:12.060 --> 00:19:14.560 what pool they are. But they don't have to do that. 00:19:15.180 --> 00:19:19.680 Yeah, and I think the argument is there because that was also, I think, in the 00:19:19.680 --> 00:19:25.670 OP, in the original email, is this idea that, you know, the way 00:19:25.670 --> 00:19:31.490 Bitcoin currently works or the current topography of the network, or at least, 00:19:31.570 --> 00:19:35.690 you know, the level of mining centralization means that in practice today, yeah, 00:19:35.830 --> 00:19:41.470 we only have 100 or whatever mining pools and they self-identify 00:19:41.470 --> 00:19:45.930 anyways. So some of these arguments don't necessarily hold up against the current 00:19:45.930 --> 00:19:51.280 state of Bitcoin. Like it's kind of similar. However… We're also designing 00:19:51.280 --> 00:19:56.720 Bitcoin for a potential future where mining really is banned 00:19:56.720 --> 00:20:01.880 worldwide, essentially. And that's where privacy becomes very important. And 00:20:01.880 --> 00:20:05.460 that's where a staking solution, like you mentioned just now, which potentially 00:20:05.460 --> 00:20:11.420 harms privacy, would therefore potentially harm mining privacy and therefore 00:20:11.420 --> 00:20:17.330 Bitcoin itself. I think that's a key thing to... take into 00:20:17.330 --> 00:20:22.910 account is that the way Bitcoin is being designed is not for today but for a 00:20:22.910 --> 00:20:24.410 potential worse tomorrow. 00:20:24.410 --> 00:20:29.630 Yeah, of course also for today but… uh there's another problem with this system. 00:20:29.630 --> 00:20:33.090 Well, you say that. Well, I don't I don't know if we want to go on a side quest 00:20:33.090 --> 00:20:38.870 on this particular topic but… Should we? I don't know. I'll just mention 00:20:38.870 --> 00:20:42.690 very briefly that I actually don't think Bitcoin is being optimized for today. 00:20:42.910 --> 00:20:47.370 That's one of Paul Sztorc's arguments for sidechains, for example, that while we 00:20:47.370 --> 00:20:52.150 live in an environment and in a world and in a regulatory environment where 00:20:52.150 --> 00:20:57.970 Bitcoin is actually just allowed and legal, then optimizing it 00:20:57.970 --> 00:21:03.760 for adversarial conditions gives it a disadvantage against systems that are not 00:21:03.760 --> 00:21:07.980 optimized for adversarial conditions because they can be more efficient and fast. 00:21:08.200 --> 00:21:13.360 And so you're sort of losing some competitive edge in that environment. But 00:21:13.360 --> 00:21:13.880 that's a… 00:21:14.350 --> 00:21:17.430 Yeah, that makes sense I mean it depends on what what aspect of the protocol 00:21:17.430 --> 00:21:21.310 you're looking at right so there are already adversaries out there so lots of 00:21:21.310 --> 00:21:25.690 privacy improvements are already being made with the idea that there is there is 00:21:25.690 --> 00:21:29.810 there already are chain analysis of chain analytics companies out there, so 00:21:29.810 --> 00:21:34.250 Yeah, that's true, but at least not really for mining apart from China I guess, 00:21:34.250 --> 00:21:38.230 and you know the solution there she just migrates from China, so we're really 00:21:38.230 --> 00:21:41.730 we're really sort of designing for a world where Bitcoin mining is banned 00:21:41.980 --> 00:21:47.520 everywhere, China everywhere, as Eric Voskuil actually literally explained it in 00:21:47.520 --> 00:21:49.100 the thread itself at some point. 00:21:49.360 --> 00:21:52.960 You want to at least have that option to be able to exist in such a system. Yeah, 00:21:53.120 --> 00:21:58.930 exactly. So another downside here is that it's very tempting 00:21:58.930 --> 00:22:02.930 for wallets to say, well, I'm not going to send it to every miner out there, 00:22:03.050 --> 00:22:06.970 every new stake out there. I might look at the pie and only send to whatever 00:22:06.970 --> 00:22:12.260 represents 80% of the mining capacity. Because maybe with 20% of the connections, 00:22:12.560 --> 00:22:18.110 you'll get your transaction to 80% of the miners. And that creates a problem for 00:22:18.110 --> 00:22:18.590 new miners. 00:22:18.590 --> 00:22:23.730 The reason for that is essentially because it's just a hassle to go and look for 00:22:23.730 --> 00:22:28.290 all of these small pools. It's much easier to just say, all right, if I get it to 00:22:28.290 --> 00:22:33.950 these 10 or these five, then it's 90% of hash power and it will almost certainly 00:22:33.950 --> 00:22:34.430 confirm. 00:22:34.710 --> 00:22:38.130 Yeah, and the wallet software is probably not going to do all this verification. 00:22:38.570 --> 00:22:41.770 It's probably going to be the wallet authors that put in a list, a hard-coded 00:22:41.770 --> 00:22:47.750 list of common miners for common pools. So that's a problem. And as Sipa 00:22:47.750 --> 00:22:52.390 Pieter Wuille pointed out, new pools could also be censored. So if you're trying 00:22:52.390 --> 00:22:57.250 to announce a new pool by staking some coins, then the existing miners could try 00:22:57.250 --> 00:23:01.310 to make sure that you never get to stake your coins. So there's also a risk there 00:23:01.310 --> 00:23:02.660 too, that it becomes a [unclear]. 00:23:02.650 --> 00:23:07.510 Right, yeah, that was an interesting argument. But let's take a small step back 00:23:07.510 --> 00:23:09.570 to the previous one. What was the previous one? 00:23:10.190 --> 00:23:16.120 That basically… wallets have an incentive to only pick a subset of the 00:23:16.120 --> 00:23:19.800 pools. And so if you're starting a new pool, you're probably very small. So 00:23:19.800 --> 00:23:21.400 nobody's going to send you any transactions. 00:23:21.680 --> 00:23:27.040 Right, exactly. So if wallets, out of convenience, prioritize the bigger pools, 00:23:27.240 --> 00:23:31.840 then it sort of locks these bigger pools in place and it becomes much harder to 00:23:31.840 --> 00:23:37.580 compete with these pools, which is bad for, again, decentralization, for example, 00:23:37.740 --> 00:23:42.710 because these big pools can be regulated more easily. If competition is more 00:23:42.710 --> 00:23:47.050 difficult then you you know it becomes harder to find your way out of such a 00:23:47.050 --> 00:23:52.870 centralized solution and then the one after that— see, 00:23:52.870 --> 00:23:56.170 my my memory is the worst what was the one that you said after that? 00:23:56.780 --> 00:23:59.120 Uh, censorship by other miners 00:23:59.120 --> 00:24:00.880 Oh, yeah yeah, so yeah so… 00:24:02.950 --> 00:24:08.470 So Zmn was going on this sort of thought experiment. Let's assume that we really 00:24:08.470 --> 00:24:11.670 want to do this. Then what are the ways to do that? And then one of the ways 00:24:11.670 --> 00:24:16.270 which we just described is to use staking as an 00:24:16.270 --> 00:24:21.790 anti-denial service type of solution. But then you 00:24:21.790 --> 00:24:27.770 need… the existing miners to allow the stake to be confirmed on the blockchain 00:24:27.770 --> 00:24:32.550 which they have an incentive not to do of course because that's also a way to 00:24:32.550 --> 00:24:35.230 keep the competition out. So yeah that was that was an interesting… 00:24:35.230 --> 00:24:38.710 And I'm sure you could continue that conversation to come up with a system that 00:24:38.710 --> 00:24:42.610 prevents even that censorship etc., but you know it's it's still a can of worms 00:24:42.610 --> 00:24:47.070 that you're opening and you know we're this whole proposal serves to close one 00:24:47.070 --> 00:24:50.790 can of worms but as we're starting to discover now the proposal is opening 00:24:50.790 --> 00:24:55.770 another several other cans of worms. So the net number of worms might actually go 00:24:55.770 --> 00:24:56.610 up if we do this. 00:24:57.900 --> 00:25:01.740 I prefer less worms. But I think we're going to see even more worms or not? 00:25:02.020 --> 00:25:07.190 Yes. So one of the arguments that was used to advocate this proposal was 00:25:07.190 --> 00:25:12.760 bandwidth. And it may be good to point out that in 00:25:12.850 --> 00:25:17.290 reality what happens is there's a lot of bandwidth to sort of gossip about which 00:25:17.290 --> 00:25:22.450 transactions exist, which is done using short identifiers. But the actual 00:25:22.450 --> 00:25:26.590 transactions themselves are usually only sent once. So your node gets a bunch of 00:25:26.590 --> 00:25:30.510 IDs and it's like, okay, give me the transactions that I don't know yet. And so 00:25:30.510 --> 00:25:32.990 that only happens once. And then… 00:25:32.990 --> 00:25:37.470 These are like recent improvements or… 00:25:37.470 --> 00:25:40.930 Yeah, I don't know what recent means for multiple years, but… 00:25:40.930 --> 00:25:42.310 Well, at least it wasn't there from the start. 00:25:43.030 --> 00:25:43.150 Yeah. 00:25:44.070 --> 00:25:48.390 Optimizations and also some optimizations moving ahead because it used to be the 00:25:48.390 --> 00:25:51.890 case indeed that every transaction was sent over the whole network and then a 00:25:51.890 --> 00:25:55.350 block was found and then the block full of all of these transactions was sent 00:25:55.350 --> 00:25:56.230 over the network as well. 00:25:56.350 --> 00:26:00.090 Well, that's the second part of this. So the transactions themselves are only 00:26:00.090 --> 00:26:06.050 sent once. but also indeed every block is sent without the 00:26:06.050 --> 00:26:09.510 transactions in it. At least if you're using this, your node will probably do 00:26:09.510 --> 00:26:13.910 that using this compact block idea where the compact block just says, here's the 00:26:13.910 --> 00:26:16.410 header of the block and here's the list of transactions that are in the block. 00:26:17.000 --> 00:26:21.180 You already have these transactions, so you can construct a block locally. You 00:26:21.180 --> 00:26:24.340 don't have to get them from me. And if you are missing any of the transactions, 00:26:24.420 --> 00:26:28.940 just ask. And in practice, that means the blocks are propagated really, really quickly. 00:26:29.910 --> 00:26:35.010 Yeah. So there's two benefits. It costs less bandwidth, which is a resource, and 00:26:35.010 --> 00:26:39.410 therefore it doesn't, it costs less resource, which is a benefit. And it 00:26:39.410 --> 00:26:43.950 transmits over the network faster, which again also 00:26:44.330 --> 00:26:50.270 helps against… pool centralization, which 00:26:50.270 --> 00:26:54.150 is another topic, which I think we probably shouldn't get into that. 00:26:54.350 --> 00:26:59.810 And basically, it's important to have very few orphans or stale blocks where if 00:26:59.810 --> 00:27:04.170 the block is still propagating around, then somebody else might also find a block 00:27:04.170 --> 00:27:07.650 at the same height. And that just increases the opportunity for double spends and 00:27:07.650 --> 00:27:11.250 it causes lost revenue for those miners. So it means it's better to be a big 00:27:11.250 --> 00:27:13.310 miner, et cetera. Now, if you want to talk about… 00:27:13.310 --> 00:27:13.930 Fast transmission is better. 00:27:14.140 --> 00:27:17.200