WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:18.190 --> 00:00:20.670 Live from Utrecht, this is Bitcoin. 00:00:21.590 --> 00:00:22.030 Explained. 00:00:22.390 --> 00:00:23.010 Hey, Sjors. 00:00:23.130 --> 00:00:24.630 Hey, Aaron. It's been a while. 00:00:25.270 --> 00:00:30.130 Yes. Welcome back on our... Hey, this is our 100th episode, Sjors. 00:00:30.250 --> 00:00:31.990 That is correct. Episode 100. 00:00:32.410 --> 00:00:37.370 I did not think we would make it with our biannual podcast. But we're back. 00:00:37.390 --> 00:00:41.830 We've exponentially approached it. Exponentially slowing down approached it. But 00:00:41.830 --> 00:00:44.950 we made it. Well, at least we made it to the start. 00:00:45.490 --> 00:00:50.710 Yeah, we're sticking to our semi-official rule to only record in person, so 00:00:50.710 --> 00:00:54.850 that's why it took a while. I was not in the Netherlands, but now I'm back in 00:00:54.850 --> 00:00:59.870 beautiful sunny Utrecht for a beautiful, fresh Bitcoin Explained episode. 00:01:00.230 --> 00:01:04.510 Exactly, and we're going to pick a very fresh topic for a node that was released 00:01:04.510 --> 00:01:05.450 only three months ago. 00:01:06.780 --> 00:01:11.200 Yes, we do make an episode. I think we've made an episode for every new Bitcoin 00:01:11.200 --> 00:01:17.080 Core release since we started the podcast. So we're at least keeping that up. But 00:01:17.080 --> 00:01:20.520 yeah, so this is Bitcoin Core 31, which came out when? 00:01:21.220 --> 00:01:22.700 In April 19th. 00:01:23.980 --> 00:01:24.360 Fantastic. 00:01:24.360 --> 00:01:28.500 And in fact, there is now a 31.1 release with some bug fixes. 00:01:28.600 --> 00:01:33.300 Right, we're not even... Well, I guess these are just bug fixes. So when did this 00:01:33.300 --> 00:01:33.700 come out? 00:01:33.840 --> 00:01:37.220 But the bug fix is related to one of the features we're going to cover. So it's 00:01:37.220 --> 00:01:39.000 good that we had to wait for this bug fix. 00:01:39.560 --> 00:01:45.340 Okay. Well, oh, is CoinKite still sponsoring us, Sjors? 00:01:45.780 --> 00:01:46.620 I think so. 00:01:47.100 --> 00:01:47.700 Should I? 00:01:47.980 --> 00:01:50.220 We're optimistically going to assume that they still are. 00:01:50.890 --> 00:01:55.090 Should I endorse or advocate for their projects just in case? 00:01:55.250 --> 00:01:56.210 We should at least thank them. 00:01:56.310 --> 00:02:02.130 Dear listener, check out CoinKite with your favorite hardware wallet 00:02:02.130 --> 00:02:07.490 vendor with the COLDCARD, the OPENDIME, the SATSCARD, the 00:02:07.490 --> 00:02:10.500 TAPSIGNER. What else do they have, Sjors? 00:02:10.800 --> 00:02:11.720 I have no idea. 00:02:12.900 --> 00:02:17.620 Definitely these things. CoinKite.com. Check it out I assume that's their website. 00:02:17.620 --> 00:02:18.380 Yes. 00:02:18.380 --> 00:02:22.140 All right. Or just Google CoinKite and see where it takes you. 00:02:22.140 --> 00:02:23.860 I'm pretty sure they have every conceivable domain. 00:02:24.240 --> 00:02:29.190 I would think so. Okay, Sjors. So Bitcoin Core 31 00:02:29.190 --> 00:02:34.710 released a couple of months ago, and you made a special selection for our dear 00:02:34.710 --> 00:02:39.990 listeners of some of the highlights in the new Bitcoin Core release. Is that right? 00:02:40.130 --> 00:02:41.390 A highly curated list. 00:02:41.990 --> 00:02:47.950 Yeah. Okay, so the first one you picked, which we'll discuss, is there's been... 00:02:48.490 --> 00:02:51.050 We wrote down Cluster mempool. 00:02:52.960 --> 00:02:58.840 Is cluster mempool... First question, is this a completely new thing? So the term 00:02:58.840 --> 00:03:03.360 cluster mempool, because I feel like I heard it before, is that just because we 00:03:03.360 --> 00:03:08.510 were discussing that it was coming? So my question is... Has cluster mempool been 00:03:08.510 --> 00:03:11.510 updated, or is cluster mempool a new thing in Bitcoin Core 31? 00:03:11.770 --> 00:03:16.330 I believe that 31 is the first version that has cluster mempool in it. The 00:03:16.330 --> 00:03:19.530 concept has been around for a few years, so it's been mentioned on different 00:03:19.530 --> 00:03:22.290 podcasts, maybe even ours, but I'm not sure. 00:03:22.850 --> 00:03:27.750 Okay, so this was a long time coming, and now, three months ago, in Bitcoin Core 00:03:27.750 --> 00:03:30.530 31, there's now cluster mempool. 00:03:30.710 --> 00:03:32.910 Yes, and you will probably not notice a difference. 00:03:33.670 --> 00:03:34.990 As a regular user? 00:03:35.190 --> 00:03:35.650 As a user, yeah. 00:03:35.770 --> 00:03:39.390 Okay, so what is cluster mempool? Just take it from the top. 00:03:40.230 --> 00:03:43.730 Well, I don't completely understand it, so maybe I'm not the right person to ask. 00:03:43.730 --> 00:03:44.430 That's a great start. 00:03:44.590 --> 00:03:48.150 But it is just a better or sane... 00:03:48.150 --> 00:03:51.530 That's why people listen to our podcast, to get sort of half-baked, they think 00:03:51.530 --> 00:03:54.430 this is how it works type of explanations. 00:03:54.810 --> 00:03:59.410 Well, it depends on the subject, but I mean, the bottom line is that it is a sane 00:03:59.410 --> 00:04:04.680 version of the mempool. The original mempool code was kind of awkward, 00:04:04.920 --> 00:04:09.770 difficult to reason about. One of the weirdest aspects of it was that... So the 00:04:09.770 --> 00:04:14.790 mempool is there to decide, or it should reflect what miners are going to mine 00:04:14.790 --> 00:04:19.670 basically first. And so ideally, if your mempool is full and you need to kick 00:04:19.670 --> 00:04:23.510 something out, then you're going to kick the most worthless transaction out and 00:04:23.510 --> 00:04:24.670 not the most valuable one. 00:04:24.870 --> 00:04:27.910 And by that you mean the transaction that pays the lowest fee? 00:04:28.030 --> 00:04:30.990 Well, not necessarily, because it's more complicated than that, right? Because 00:04:30.990 --> 00:04:34.070 it's not just about the fee that your transaction pays, but it's also how much 00:04:34.070 --> 00:04:38.550 your parents pay or how much your uncles... and nephews and et cetera pay. 00:04:38.730 --> 00:04:39.890 And I guess that's the point. 00:04:40.050 --> 00:04:43.910 And that was very complicated to reason about. So there were some strange 00:04:43.910 --> 00:04:48.330 scenarios where if the mempool was full, you would actually kick out the 00:04:48.330 --> 00:04:51.790 transaction that if you were a miner would be the first one you'd want to mine 00:04:51.790 --> 00:04:55.690 because of this intricate relationships between transactions. 00:04:56.030 --> 00:05:01.870 Okay, but the simple example of this is child pays for parents, right? 00:05:02.130 --> 00:05:08.090 So there's a transaction that pays a very low fee, but from that transaction are 00:05:08.090 --> 00:05:13.570 coins spent again in a new transaction that pays a high fee. So as a miner... 00:05:13.760 --> 00:05:17.820 You want to mine both of those, including the very low fee transaction, because 00:05:17.820 --> 00:05:20.120 then you also get the high fee from the next transaction. 00:05:20.420 --> 00:05:23.860 Yeah, and as far as I know, that worked. But once you make the scenarios more 00:05:23.860 --> 00:05:26.220 complicated, things do not behave very well. 00:05:26.480 --> 00:05:31.340 Yeah, but so that's the point I'm making. That already worked, right? Bitcoin 00:05:31.340 --> 00:05:36.700 Core already had at least the basic child pays for parent logic. 00:05:37.540 --> 00:05:39.320 Also in the mempool, I think, right? 00:05:39.540 --> 00:05:43.220 Yeah, as far as I, my limited understanding is that it was able to reason 00:05:43.220 --> 00:05:48.060 basically from the ancestors down to the children or from the children up to the 00:05:48.060 --> 00:05:51.760 ancestors. Like you can go down the family graph up or down. 00:05:52.000 --> 00:05:52.540 Like one step. 00:05:52.580 --> 00:05:57.690 But not sideways. And I think now it can take into account like, oh, you know, 00:05:57.770 --> 00:06:01.030 this parent and child are worthless, but they have a rich cousin that's paying a 00:06:01.030 --> 00:06:04.650 lot of fees. And so we should include that. 00:06:04.750 --> 00:06:08.570 So they're connected through, I don't know, like the grandfather in this analogy. 00:06:09.130 --> 00:06:10.530 You could just draw more. 00:06:10.630 --> 00:06:12.010 Yeah, so you have a parent, a child. 00:06:12.030 --> 00:06:18.010 The term cluster kind of says it. You can take a bigger cluster of transactions 00:06:18.010 --> 00:06:24.000 into account. when it comes to which transactions you want to keep in the mempool 00:06:24.000 --> 00:06:26.040 or kick out of the mempool. 00:06:26.160 --> 00:06:30.500 Yeah and where this becomes important is we have talked about this previously I 00:06:30.500 --> 00:06:35.260 think in equally vague terms things like pinning attacks where you're trying to 00:06:35.260 --> 00:06:38.760 escape from a Lightning channel so you broadcast a transaction and then somebody 00:06:38.760 --> 00:06:43.840 else makes a child of that transaction that makes it so that you will never get 00:06:43.840 --> 00:06:48.140 confirmed because the total fee is too low and so you want to bump that fee but 00:06:48.140 --> 00:06:52.700 you can't because you hit some sort of limit and there's a lot of these annoying 00:06:52.700 --> 00:06:54.140 complicated cases. 00:06:55.470 --> 00:06:58.810 Real quick, I don't know if you know the answer to this question, but is it the 00:06:58.810 --> 00:07:04.060 case that the more sophisticated miners and mining pools were 00:07:04.060 --> 00:07:08.900 practically already doing this, but Bitcoin Core was just not keeping up and 00:07:08.900 --> 00:07:13.320 therefore mempools weren't really reflecting what was actually being mined? Or is 00:07:13.320 --> 00:07:15.900 this also really an innovation that miners are going to use? 00:07:16.100 --> 00:07:21.280 There's a couple of different things happening here. As far as people that have 00:07:21.280 --> 00:07:26.680 looked at what blocks look like, the quirks in the blocks suggest that they use 00:07:26.680 --> 00:07:31.120 Bitcoin Core to decide what goes in the block. However, they might have tweaked 00:07:31.120 --> 00:07:36.700 things like the minimum fee rate. So last summer we saw that... 00:07:36.680 --> 00:07:42.600 suddenly miners started including 0.1 sats per vbyte transactions. And that is a 00:07:42.600 --> 00:07:47.780 case of the miners are ahead of what Bitcoin Core was doing by default. And then 00:07:47.780 --> 00:07:50.820 Bitcoin Core tends to follow what the miners are doing because of this rule that 00:07:50.820 --> 00:07:53.860 we want to basically anticipate what's going to be mined. 00:07:55.400 --> 00:07:59.540 So I wouldn't say that they use some sort of sophisticated algorithm as far as I 00:07:59.540 --> 00:08:04.460 know. In fact, it's kind of the opposite. If the mempool is not as sophisticated 00:08:04.460 --> 00:08:09.470 as it can be, There is an incentive for somebody to say, hey, I can make better 00:08:09.470 --> 00:08:13.550 block templates than Bitcoin Core does. Why don't you send the transactions to me 00:08:13.550 --> 00:08:19.270 as sort of an accelerator? And then you get centralization pressure. So Bitcoin 00:08:19.270 --> 00:08:24.330 Core kind of needs to be as good as possible while not wasting too many resources 00:08:24.330 --> 00:08:28.130 of the node. Because there's a computational time there, right? Every time a 00:08:28.130 --> 00:08:31.210 transaction comes in, you need to do some calculation to see if it's good or bad. 00:08:32.090 --> 00:08:37.990 Yeah, as good as possible from the... perspective of a miner that wants 00:08:37.990 --> 00:08:40.430 to maximize fee revenue, right? 00:08:40.650 --> 00:08:40.890 Yes. 00:08:42.390 --> 00:08:48.290 Was this just something that was kind of always on Bitcoin Core's to 00:08:48.290 --> 00:08:52.790 -do list, but it's hard and it's complicated and that's why it took a while? Or is 00:08:52.790 --> 00:08:56.890 there a more specific reason it was implemented? 00:08:58.110 --> 00:09:01.370 I think you told me that it has something to do with Ark maybe also. 00:09:01.670 --> 00:09:06.490 No, it predates it. So the idea of cluster mempool predates Ark, I think by 00:09:06.490 --> 00:09:07.150 several years. 00:09:07.390 --> 00:09:07.590 Okay. 00:09:08.190 --> 00:09:13.710 I mean, over the past 10 years or so, I guess since Lightning especially, there's 00:09:13.710 --> 00:09:18.390 been a lot of discussion about pinning attacks that I just described before. And 00:09:18.390 --> 00:09:22.250 then you have things like RBF, which has a bunch of different rules. Like it has 00:09:22.250 --> 00:09:26.030 some rules in the BIP and it has some rules, actual rules that are not in the BIP. 00:09:27.400 --> 00:09:32.330 And, you know, it got quite convoluted. It wasn't very elegant. It was kind of a 00:09:32.330 --> 00:09:36.810 hot, sort of a hodgepodge of, well, if we make this rule and this exception, and 00:09:36.810 --> 00:09:41.470 then, you know, we have a carve out here. It was kind of a messy set of rules 00:09:41.470 --> 00:09:45.850 that was just good enough, but then people kept finding ways to still pin you as 00:09:45.850 --> 00:09:49.410 a Lightning operator. So there were stakes. And this was kind of a redesign of 00:09:49.410 --> 00:09:53.850 it, which people came up with several years ago, thinking of how can we design 00:09:53.850 --> 00:09:58.990 the mempool logic from scratch. the sorting logic from scratch in a way that 00:09:59.310 --> 00:10:03.770 gets rid of all these weird exceptions too. So I think a couple of rules have 00:10:03.770 --> 00:10:08.960 been dropped in how RBFs are processed and exceptions have been removed. So it's 00:10:08.960 --> 00:10:10.760 more elegant and it seems to be more robust. 00:10:10.940 --> 00:10:15.180 Okay. And this is a very, I mean, we're talking about the mempool as a kind of a 00:10:15.180 --> 00:10:18.760 very individual thing in the sense of you have your own mempool and, you know, 00:10:18.840 --> 00:10:23.540 every node has that. But this, I assume automatically, or I mean, you can answer 00:10:23.540 --> 00:10:27.180 it automatically. This also applies to what you share with your peers. 00:10:29.180 --> 00:10:33.840 As far as I know, you share with your peers the moment you add it into your own mempool. 00:10:33.980 --> 00:10:34.500 Right, exactly. 00:10:34.740 --> 00:10:38.960 So that doesn't really change. I mean, if for some reason a transaction now goes 00:10:38.960 --> 00:10:42.280 into your mempool because of these different heuristics, give a slightly 00:10:42.280 --> 00:10:44.920 different result, then yeah, you would be sharing it with your peers. 00:10:45.510 --> 00:10:50.550 Yeah, but that was like a whole project, right? That Gloria in particular was 00:10:50.550 --> 00:10:55.070 working on, I think, with the package relay. So is this related to that? Is this 00:10:55.070 --> 00:10:56.730 kind of the same project in that sense? 00:10:56.870 --> 00:10:59.550 So my understanding is that this will make package relay... 00:11:01.320 --> 00:11:06.080 So what we discussed in a previous episode, the one parent, one child, special 00:11:06.080 --> 00:11:10.280 case of package relay. So it's a package of two. And this is quite useful because 00:11:10.280 --> 00:11:12.760 if you need to get out of a Lightning channel, that's usually just two 00:11:12.760 --> 00:11:17.540 transactions. One is the penalty transaction that you want to apply or the escape 00:11:17.540 --> 00:11:21.800 transaction. And the other is the fees that you want to add because when you make 00:11:21.800 --> 00:11:26.060 the channel, you agreed on either very low fees or in the case of ephemeral dust, 00:11:26.240 --> 00:11:31.920 no fees at all. And so the special case of two was possible 00:11:31.920 --> 00:11:36.160 even without cluster mempool. But the hope is that with cluster mempool, you can 00:11:36.160 --> 00:11:40.300 reason about a much larger set of transactions. And then my optimistic take, and 00:11:40.300 --> 00:11:44.380 could be wrong, is that things like Ark would now become possible. Because with 00:11:44.380 --> 00:11:48.840 Ark, you have, say, 25 transactions to get out. And don't ask me how Arks work. 00:11:50.600 --> 00:11:55.500 You might have a package of 25 because you have a tree of transactions that are 00:11:55.500 --> 00:12:00.840 needed to escape. But right now, the nodes tend to process transactions one at a 00:12:00.840 --> 00:12:05.660 time. Whereas in such a scenario, maybe all the transactions don't pay enough 00:12:05.660 --> 00:12:09.960 fees except the very last one, which pays all the fees. And the node needs to 00:12:09.960 --> 00:12:14.100 understand that it needs to consider all 25 of them and that the last one is 00:12:14.100 --> 00:12:18.180 paying all the fees. And I think that's possible with package relay. And then 00:12:18.180 --> 00:12:21.680 hopefully cluster mempool makes it so that the node can reason about these big 00:12:21.680 --> 00:12:25.360 packages. It doesn't right now. It just has the better architecture under it. 00:12:28.210 --> 00:12:32.590 Sorry, that last sentence caught me off guard. It doesn't have it right now? 00:12:32.730 --> 00:12:36.530 No. We have cluster mempool, so it's a better architecture that might allow 00:12:36.530 --> 00:12:39.750 packages larger than two, but we don't do that yet. 00:12:40.970 --> 00:12:44.970 Oh, okay, but that gets back to how do you even get the transactions in the first 00:12:44.970 --> 00:12:48.330 place and if other pairs don't get the whole cluster to you? 00:12:49.790 --> 00:12:54.710 Well, okay, so the cluster is a bunch of transactions that might have been given 00:12:54.710 --> 00:12:58.370 to you sequentially. So it builds up over time. 00:12:58.610 --> 00:13:02.590 Right. But you need to keep them in order to know if the child or the parents are 00:13:02.590 --> 00:13:05.710 also valid, right? You need to not eject them, which is the point. 00:13:05.910 --> 00:13:09.310 Yeah. When you start out, you will accept anything that's over one sat per V-byte 00:13:09.310 --> 00:13:11.150 because your mempool is empty. You've got 300 megabytes. 00:13:11.390 --> 00:13:13.390 Yeah, or 0.1 sat per V-byte, I think. 00:13:13.590 --> 00:13:17.630 Yes, exactly. So you build up this mempool, including the clusters that are in it 00:13:17.630 --> 00:13:21.530 of related transactions. And then at some point, your mempool starts overflowing. 00:13:21.670 --> 00:13:25.020 And so you now have to decide which one are you going to throw out. And that is 00:13:25.020 --> 00:13:28.380 when you look at these clusters and you find the worst cluster and then each 00:13:28.380 --> 00:13:33.460 cluster is divided into chunks. So you take any given set of transactions that 00:13:33.460 --> 00:13:39.400 are related as a cluster and you kind of squash it in a line in a way 00:13:39.400 --> 00:13:43.060 that the best part of the cluster is at the top and the worst part of the cluster 00:13:43.060 --> 00:13:48.800 is at the bottom. And so you take the worst part of the cluster and you throw 00:13:48.800 --> 00:13:51.380 that out. And that's a very fast calculation now. 00:13:52.280 --> 00:13:55.580 Okay, but you throw that out in a way that the rest of the cluster is still 00:13:55.580 --> 00:13:56.080 valid. 00:13:56.280 --> 00:14:00.440 Yes, so the way you squash the cluster, like you flatten it, you flatten it in a 00:14:00.440 --> 00:14:05.300 way that one side of it doesn't need the other side of it. 00:14:06.180 --> 00:14:09.900 There's a certain order to it. So you want to order transactions by the most fees 00:14:09.900 --> 00:14:14.720 first, whenever possible. But if that's not possible because there's a child for 00:14:14.720 --> 00:14:18.880 parents, you might have the first transaction is a cheap parent, the second 00:14:18.880 --> 00:14:23.480 transaction is a... cheap child, and then the third transaction is a 00:14:23.480 --> 00:14:29.070 grandchild that pays a lot. And that's the first chunk. And then the next chunk 00:14:29.070 --> 00:14:34.410 might be some other uncle transaction that pays a little bit less than the super 00:14:34.410 --> 00:14:39.430 rich child, etc. And that means that if you cut the tail off from the cluster, 00:14:40.000 --> 00:14:43.480 you're throwing away the least valuable part of it, but you're keeping it. And 00:14:43.480 --> 00:14:48.360 you can cut it at multiple places. But not at all places, right? Because like you 00:14:48.360 --> 00:14:53.640 said, some transactions depend on each other. And so it's sorted in a way that 00:14:53.640 --> 00:14:56.900 you can cut it in a number of places without breaking those dependencies. 00:14:58.410 --> 00:14:58.770 Right. 00:14:58.950 --> 00:15:03.330 And then you cut the worst part. And for mining, you do the opposite. So for 00:15:03.330 --> 00:15:05.970 mining, you look at the best cluster and the best part of the cluster. 00:15:07.570 --> 00:15:12.990 Maybe I'm going a bit too much into the weeds right now, but in this hypothetical 00:15:12.990 --> 00:15:16.910 scenario that you describe, you're starting with an empty mempool, basically. 00:15:17.530 --> 00:15:23.130 But in this scenario that you describe, you're starting with an empty mempool, basically. 00:15:23.220 --> 00:15:23.660 Yes. 00:15:23.470 --> 00:15:27.550 But in reality, most of the time, you don't start with an empty mempool. Your 00:15:27.550 --> 00:15:29.710 mempool is kind of always full by default, right? 00:15:29.930 --> 00:15:34.690 Well, not today, but let's say it is full, and a new transaction comes in. So 00:15:34.690 --> 00:15:38.350 then what you have to do, as far as I understand it, is you look at your mempool 00:15:38.350 --> 00:15:42.090 and see which is this relevant to any of the clusters I have, or is it a 00:15:42.090 --> 00:15:46.200 completely new cluster because it's unrelated to anything I've seen. If it is a 00:15:46.200 --> 00:15:50.960 new cluster, then you just see, okay, is this new cluster better than any of my 00:15:50.960 --> 00:15:51.640 existing clusters? 00:15:51.740 --> 00:15:54.540 But then you need the other transactions in the cluster as well, right? 00:15:55.580 --> 00:15:56.780 Otherwise, how can you tell? 00:15:56.940 --> 00:16:00.140 So a new transaction can be a cluster of one. It's not related to anything else 00:16:00.140 --> 00:16:03.280 in the mempool. It's basically just spending from something that's confirmed. 00:16:03.520 --> 00:16:07.080 Yes, but what if that is a very low fee-paying transaction and you don't see the 00:16:07.080 --> 00:16:10.620 rest of the cluster yet, then you would normally throw it out, even though maybe the rest of it... 00:16:10.620 --> 00:16:12.760 Yeah, so if you receive a new transaction... 00:16:12.760 --> 00:16:15.420 So for that, you need package relay, ultimately, right? Or some form of it that 00:16:15.420 --> 00:16:16.700 is so compatible with... 00:16:16.700 --> 00:16:20.540 Yeah, so if you see a new transaction that is not related to any of the clusters 00:16:20.540 --> 00:16:25.080 you're aware of, but it is part of a cluster, apparently... then yeah, you might 00:16:25.080 --> 00:16:30.040 just reject it. And you'd need something like package relay, especially big 00:16:30.040 --> 00:16:33.720 package relay to say, okay, here's somebody escaping from their Ark, for example, 00:16:33.860 --> 00:16:38.660 25 transactions. I see the first one of that 25 transactions. I'm like, well, 00:16:38.720 --> 00:16:42.320 this is a new cluster, but it pays nothing. So I'm going to ignore it. And the 00:16:42.320 --> 00:16:46.340 second one, I'm also going to ignore it because it's paying from a parent that I, 00:16:46.520 --> 00:16:50.160 you know, spending from a parent that I don't know about. So that's where this 00:16:50.160 --> 00:16:53.810 comes in. But in the case where it's just a single transaction and you need to 00:16:53.810 --> 00:16:58.920 evaluate it on its own, either it's better than any of your clusters or parts of 00:16:58.920 --> 00:17:02.280 the clusters, and then you know where to sort it and you put it in the mempool, 00:17:02.480 --> 00:17:07.020 or it's not and you ignore it. And that's a fast calculation, so you can do that 00:17:07.020 --> 00:17:08.800 when you get lots of new transactions every second. 00:17:09.220 --> 00:17:12.620 Okay, so then I think this will be my last question on this topic. 00:17:14.280 --> 00:17:18.700 Ideally, we'd want package relay for clusters, right? 00:17:19.240 --> 00:17:21.760 I think so, but some people might say no. 00:17:23.260 --> 00:17:24.020 I'm not sure. 00:17:24.180 --> 00:17:26.900 But in any case, that's not here yet. That's not here yet. 00:17:27.040 --> 00:17:30.080 No, the only package relay for clusters is a cluster of two. 00:17:30.380 --> 00:17:34.660 Okay, right. Okay, well, that answers my question. That was my question. So right 00:17:34.660 --> 00:17:39.080 now, cluster mempool works for your mempool, and you make more complicated, 00:17:39.320 --> 00:17:44.780 complex, advanced. calculations for that, but it's not necessarily all related as 00:17:44.780 --> 00:17:45.380 a package yet. 00:17:45.880 --> 00:17:46.100 Exactly. 00:17:46.380 --> 00:17:49.720 And maybe you say there's arguments against doing that also. 00:17:50.360 --> 00:17:54.520 Maybe. I mean, if you look at the one child, one parent example in Lightning, the 00:17:54.520 --> 00:17:58.920 TRUC transactions or the ephemeral dust transactions, the question there is what 00:17:58.920 --> 00:18:03.700 is the maximum cost that an attacker can impose on you? So right now I think 00:18:03.700 --> 00:18:05.180 that's capped at like 10,000. 00:18:06.590 --> 00:18:10.890 sats in total, so that's like $5 now, the worst that the attacker can do to you. 00:18:11.070 --> 00:18:15.210 But if you say, okay, we're allowing a cluster package of size million 00:18:15.210 --> 00:18:18.750 transactions, then, I don't know, maybe the attacker can do more damage to you. 00:18:19.370 --> 00:18:21.850 But maybe that's not too bad. I don't know. 00:18:22.570 --> 00:18:27.550 Okay, in any case, short summary, cluster mempool, your node, your mempool, 00:18:27.910 --> 00:18:32.670 will make more advanced calculations to determine what to keep and what to throw 00:18:32.670 --> 00:18:37.830 out. which benefits miners that would use this to create blocks and individual 00:18:37.830 --> 00:18:42.430 nodes because then their mempools better reflect the blocks that are actually 00:18:42.430 --> 00:18:47.730 mined, which benefits the estimation and stuff like that and relay. Correct? 00:18:48.030 --> 00:18:51.630 Yeah, I think some of this will or is being used for fee estimation too. 00:18:52.470 --> 00:18:52.570 Right. 00:18:54.280 --> 00:18:57.460 Does that conclude our topic? 00:18:57.620 --> 00:18:58.680 Yeah, I think so. We can move on. 00:18:59.460 --> 00:19:03.860 Okay. So the next upgrade in Bitcoin Core 31, 00:19:04.390 --> 00:19:08.130 there's now a function called private broadcast. 00:19:09.090 --> 00:19:11.170 A startup option called private broadcast. 00:19:11.390 --> 00:19:14.030 A startup option called private broadcast. Okay. 00:19:14.210 --> 00:19:19.190 And it's been fixed in version 31.1. So if you want to use it, you should use 31 00:19:19.190 --> 00:19:24.710 .1 to be on the safe side. What it does is, so right now, if you make a 00:19:24.710 --> 00:19:28.550 transaction and you send it, it just goes to a bunch of your peers. 00:19:29.870 --> 00:19:33.270 And that's not great if one of your peers happens to be Chainalysis and they can 00:19:33.270 --> 00:19:37.310 sort of figure out, oh, well, I saw it from you first and not from others, so 00:19:37.310 --> 00:19:40.970 maybe it's yours, right? So you're kind of leaking, potentially leaking the 00:19:40.970 --> 00:19:45.440 origin of your own transaction. In the past, there were proposals like Dandelion. 00:19:45.680 --> 00:19:46.800 I don't know if we've ever covered that. 00:19:47.100 --> 00:19:48.440 Oh, that's years ago. 00:19:48.640 --> 00:19:48.880 Yes. 00:19:48.960 --> 00:19:52.080 That's like a 10-year-old proposal. I don't think we ever covered that. 00:19:52.180 --> 00:19:56.020 Okay. Yeah, it's quite an old proposal. It's quite cool, but it basically said, 00:19:56.080 --> 00:19:59.900 okay, we're going to send a transaction, one hop, another hop, another hop, like 00:19:59.900 --> 00:20:04.480 just as a stem basically, and then it explodes at some random node in the distance. 00:20:04.740 --> 00:20:04.880 Right. 00:20:05.460 --> 00:20:09.400 That turns out to be extremely complicated to implement for all sorts of reasons. 00:20:11.210 --> 00:20:15.810 But there's a sort of a poor man's dandelion, I guess, where it's this. So 00:20:15.810 --> 00:20:20.730 instead of connecting to your peers, when you have this new transaction, you open 00:20:20.730 --> 00:20:22.150 a new Tor connection. 00:20:23.350 --> 00:20:25.250 Just good old Tor? 00:20:25.450 --> 00:20:30.680 Yes. Completely new Tor circuit, I think. And then you find a peer randomly on 00:20:30.680 --> 00:20:35.870 the internet. You connect to it. You say, hi, here's the transaction. Bye. And 00:20:35.870 --> 00:20:40.520 then you wait. And you see if any of your peers, normal peers, announced this transaction. 00:20:40.960 --> 00:20:41.800 To you, basically. 00:20:41.800 --> 00:20:44.780 To you, because then you know it kind of went through the network. If not, then 00:20:44.780 --> 00:20:47.580 you just keep trying another Tor peer, etc. 00:20:48.530 --> 00:20:48.890 Right. 00:20:48.990 --> 00:20:51.370 So this is still a bit cumbersome to use, but it's there. 00:20:52.360 --> 00:20:56.680 Right, right, yeah. Okay, so yeah, the problem, I mean, yeah, one of the ways to 00:20:56.680 --> 00:21:02.610 de-anonymize Bitcoin users is basically for, you know, the companies 00:21:02.610 --> 00:21:04.630 like Chainalysis. 00:21:06.020 --> 00:21:07.180 Am I pronouncing it? 00:21:07.340 --> 00:21:09.680 There are different people who pronounce it in different ways for different 00:21:09.680 --> 00:21:10.620 reasons, but it's Chainalysis. 00:21:11.100 --> 00:21:15.420 But there's different companies, right? They actually monitor the Bitcoin network 00:21:15.420 --> 00:21:19.960 itself to see where transactions originate, which is not 00:21:19.960 --> 00:21:25.780 foolproof, but at least it's supposedly used, right? 00:21:26.140 --> 00:21:29.980 Yeah, so the first peer that you, if you're a spy and you're connecting to lots 00:21:29.980 --> 00:21:33.880 of different nodes, and the first node you hear about for a given transaction is, 00:21:33.980 --> 00:21:38.060 you know, more likely to be the original one than the second node you hear it from. 00:21:38.280 --> 00:21:42.340 Yeah, exactly. Okay, so the, and then the solution now is to use, to just use, 00:21:42.480 --> 00:21:48.410 sounds simple enough. Why is this new? I would say, I mean, I 00:21:48.410 --> 00:21:52.870 didn't propose it 10 years, so it's easy to say now, but you would think someone 00:21:52.870 --> 00:21:58.400 could have just come up with this 10 years ago. Is there something difficult 00:21:58.400 --> 00:21:59.020 about this? 00:22:00.620 --> 00:22:04.540 No, I suspect the idea itself actually might already be at least five years old, 00:22:04.580 --> 00:22:05.040 if not more. 00:22:06.320 --> 00:22:10.580 It's possible that somebody proposed it, then came up with Dandelion. That sounds 00:22:10.580 --> 00:22:14.220 really cool. And then you try that and it doesn't work. It took another five 00:22:14.220 --> 00:22:18.520 years to get this one-shot Tor thing through. I think the idea is not super new. 00:22:19.140 --> 00:22:23.060 The downside, I think, is relying on Tor. Because it's kind of like this black 00:22:23.060 --> 00:22:27.460 box trust assumption. Like, okay, we hope Tor actually works and doesn't. Because 00:22:27.460 --> 00:22:32.800 if this doesn't work, let's say Tor was fake. Like, it doesn't actually protect 00:22:32.800 --> 00:22:37.640 your privacy. Then you are creating a connection to the spy agency and telling 00:22:37.640 --> 00:22:39.100 them, this is my transaction. 00:22:39.400 --> 00:22:40.760 And I want to keep it private. 00:22:40.980 --> 00:22:45.060 Because you're only using this connection to send your transactions. There's no 00:22:45.060 --> 00:22:45.520 decoys. 00:22:46.790 --> 00:22:48.730 Yeah, it's a dependency, right? 00:22:50.010 --> 00:22:51.810 Ideally, you would not want to... 00:22:51.300 --> 00:22:54.170 And there's some practical issues. How do you configure your node to use Tor, 00:22:54.310 --> 00:22:57.990 etc.? Now, a lot of these node-in-the-box solutions will do that for you. 00:22:59.400 --> 00:23:04.720 Okay, so this is new in Bitcoin Core 31, because 00:23:04.720 --> 00:23:08.780 it's not by default, right? You have to actually opt in somehow? 00:23:08.800 --> 00:23:11.680 Yeah, you have to turn on a setting, and then you have to do something special 00:23:11.680 --> 00:23:13.660 when you make a transaction to use this, I think. 00:23:14.540 --> 00:23:19.260 Okay, and if I understand correctly, this is not implemented in the wallet right 00:23:19.260 --> 00:23:24.320 now. As a Bitcoin Core wallet user, you can't use this. You would have to... What 00:23:24.320 --> 00:23:26.720 do you actually have to do? You have to construct your own transaction and 00:23:26.720 --> 00:23:27.340 then... 00:23:27.340 --> 00:23:30.200 Yeah, I think you create the transaction as normal, but you don't send it, you 00:23:30.200 --> 00:23:34.860 don't broadcast it, you just copy it and then send it over, copy it to an RPC command. 00:23:35.770 --> 00:23:36.130 Okay. 00:23:36.330 --> 00:23:37.190 So it's a little tedious, but... 00:23:37.190 --> 00:23:38.490 It's a little bit manual labor. 00:23:38.790 --> 00:23:43.530 Yeah, but I can imagine that you could add this to the wallet. It's not rocket 00:23:43.530 --> 00:23:44.990 science, it's just one step at a time. 00:23:46.120 --> 00:23:51.500 Yeah. Okay, so that's a new option, that's a new feature in Bitcoin Core 31. I 00:23:51.500 --> 00:23:55.140 think that basically covers it, right? It's kind of straightforward, or is there 00:23:55.140 --> 00:23:55.940 more to say about this? 00:23:56.700 --> 00:23:57.580 Yeah, no, that covers it. 00:23:57.840 --> 00:24:00.740 Okay, great. More privacy is great. I like it. Okay. 00:24:03.320 --> 00:24:03.680 ASMAP. 00:24:04.410 --> 00:24:10.350 Or ASMAP, depending on your mood. We had an episode about this, so just listen to it. 00:24:12.880 --> 00:24:13.840 Back then, we... 00:24:13.840 --> 00:24:17.100 Did we do a whole episode on only ASMAP? 00:24:17.100 --> 00:24:21.440 I think so. We had a whole bunch of episodes about eclipse attacks, and one of 00:24:21.440 --> 00:24:22.560 them was about ASMAP. 00:24:22.960 --> 00:24:26.920 Okay, but to recoup that a little bit. 00:24:27.080 --> 00:24:30.040 The quick summary is that we don't like eclipse attacks. 00:24:30.220 --> 00:24:31.600 What is an eclipse attack again? 00:24:31.640 --> 00:24:34.600 It's where you are connected to only one. 00:24:36.130 --> 00:24:37.270 Pretending to be several. 00:24:37.450 --> 00:24:40.630 Pretending to be several. And then they can feed you maybe an alternative 00:24:40.630 --> 00:24:45.390 blockchain or pretend there's no update or all sorts of shenanigans you don't want. 00:24:45.510 --> 00:24:51.170 If every pair you're connecting to is actually the same attacker, then they can 00:24:51.170 --> 00:24:56.470 give you blocks that are... double spending or whatever. It's not necessarily the 00:24:56.470 --> 00:24:57.710 largest chain you're seeing then. 00:24:57.850 --> 00:25:02.310 And if you are a miner, then they can make you produce a block that's not 00:25:02.310 --> 00:25:07.430 actually on the most work chain, and then they can abuse you to double spend 00:25:07.430 --> 00:25:11.930 somebody else. So it's not just you as a normal node, but it's also you as a 00:25:11.930 --> 00:25:15.300 miner node where you do not want to be eclipsed. 00:25:16.080 --> 00:25:20.880 Yeah. Bottom line, you want to be connected to the actual network. You want to 00:25:20.880 --> 00:25:25.390 see actual blocks that the rest of the network sees. So an eclipse attack stops 00:25:25.390 --> 00:25:31.270 that. So this is a solution, or this is a measure against eclipse attacks. 00:25:31.450 --> 00:25:34.610 Yeah, so over the years, lots of different measures have been taken to prevent 00:25:34.610 --> 00:25:38.650 eclipse attacks. One of the measures that's been in there for quite long, I think 00:25:38.650 --> 00:25:42.960 from the beginning, is that when we decide who to connect to, 00:25:43.140 --> 00:25:48.980 we use this thing called buckets. We have a whole 00:25:48.980 --> 00:25:53.890