WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.410 --> 00:00:10.270 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:10.490 --> 00:00:11.310 Hello again. 00:00:12.810 --> 00:00:14.090 We've done it again, Sjors. 00:00:14.290 --> 00:00:15.090 We've done it again. 00:00:15.190 --> 00:00:19.830 We recorded the whole episode without actually recording it. Yeah. So we're going 00:00:19.830 --> 00:00:20.730 to do the whole thing over. 00:00:20.870 --> 00:00:23.790 It's this thing where you press the button, but you don't press it hard enough. 00:00:24.190 --> 00:00:27.430 And you have to check if the red light is blinking. It is now. 00:00:27.900 --> 00:00:33.420 Great. I think you have a bit of news, some exciting news for us. 00:00:33.540 --> 00:00:36.940 That's right. You can now stream your sats to us. 00:00:38.560 --> 00:00:40.720 Yeah, you can. It's very cool. 00:00:41.160 --> 00:00:42.100 How does that work? 00:00:42.300 --> 00:00:43.500 So there's this thing called podcasting. 00:00:43.500 --> 00:00:46.500 And us is our podcast. Us is the Van Wirdum Sjorsnado. 00:00:46.860 --> 00:00:47.340 That's right. 00:00:47.620 --> 00:00:49.120 You can stream sats to Sjors and me. 00:00:49.340 --> 00:00:53.750 That's right. Uh, the… the way it works is this standard called podcasting 2.0. 00:00:54.080 --> 00:00:59.940 So for those who don't know, a podcast is essentially just an RSS feed with 00:00:59.940 --> 00:01:04.130 a bunch of information like the title and a nice picture. And for every episode, 00:01:04.170 --> 00:01:08.490 a link to some MP3 file that your podcast player downloads. But it turns out you 00:01:08.490 --> 00:01:14.370 can add more stuff to this RSS feed than Adam Curry, the original podcaster. He 00:01:14.370 --> 00:01:18.410 basically started a project called Podcasting 2.0, which adds a bunch of new 00:01:18.410 --> 00:01:24.210 fields. And one of those new fields is called value. And this value field lets 00:01:24.210 --> 00:01:30.120 you add, for example, a Lightning node public key to 00:01:30.120 --> 00:01:33.820 the RSS feed of your podcast. And then if you have a podcast player that 00:01:33.820 --> 00:01:39.190 understands this, like a normal podcast player will just ignore it, but a player 00:01:39.190 --> 00:01:44.650 like in the Breez iOS TestFlight app, I think also like in the Sphinx app, 00:01:45.420 --> 00:01:50.620 if they understand it, they will, and they have Lightning available, they'll 00:01:50.620 --> 00:01:55.160 start streaming sats to you as the people are listening. And you can suggest a 00:01:55.160 --> 00:01:56.440 rate, but people can choose it themselves. 00:01:57.740 --> 00:02:01.240 So people can either listen for free or they can pay us. 00:02:01.400 --> 00:02:02.160 That's right. 00:02:02.680 --> 00:02:04.240 Well, let's see what they choose. 00:02:04.160 --> 00:02:08.040 So, not only that they can… they can listen for free in a really you know, 00:02:08.040 --> 00:02:13.140 well-functioning uh, app maintained by Apple or they can use very experimental 00:02:13.140 --> 00:02:18.640 software and like have to deal with Lightning and… and then pay us. Um, we'll see 00:02:18.640 --> 00:02:19.960 which… which people prefer. 00:02:20.880 --> 00:02:23.480 Sounds like we're going to be stacking sats, Sjors. 00:02:23.760 --> 00:02:27.720 Yeah. I think the last time I checked the node, it was zero sats in it, but it's 00:02:27.720 --> 00:02:28.740 only been live for a couple hours. 00:02:29.300 --> 00:02:32.540 The other thing I wanted to mention is people keep pinging me about the coin 00:02:32.540 --> 00:02:34.780 flip. Did you hear about the coin flip? 00:02:34.960 --> 00:02:38.140 I did because you just told me in the previous take. But tell me again. 00:02:38.220 --> 00:02:42.320 I'm trying to pretend a little bit like this is an original episode. 00:02:42.700 --> 00:02:43.760 All right. I'll try that. 00:02:43.880 --> 00:02:49.540 So the Speedy Trial… the discussion was winding down to 00:02:49.540 --> 00:02:54.180 block height or block time, which we discussed in our episode about Speedy Trial. 00:02:54.380 --> 00:02:54.780 That's right. 00:02:54.920 --> 00:02:56.540 That was about Taproot activation. 00:02:56.840 --> 00:03:00.880 And the difference is basically, at least I find block height a little bit easier 00:03:00.880 --> 00:03:05.380 to understand, but the existing software so far in BIP 9 have all used block 00:03:05.380 --> 00:03:07.040 height, which is fine. 00:03:07.320 --> 00:03:07.700 No, block time. 00:03:07.960 --> 00:03:13.100 Block time, sorry, which is fine. It's just a little bit more difficult to think 00:03:13.100 --> 00:03:16.480 about, but in terms of code, I don't think it matters that much. So there's now 00:03:16.480 --> 00:03:17.240 two pull requests. 00:03:17.700 --> 00:03:21.840 Yeah, and it looks like it's going to be the block time one based on a 00:03:21.840 --> 00:03:24.260 blockchain-based coin flip they did. 00:03:24.730 --> 00:03:27.350 That's amazing, even though, you know, they can be gamed. 00:03:30.870 --> 00:03:35.490 This was mentioned on the IRC chat as well. But, you know, it would be pretty 00:03:35.490 --> 00:03:36.550 expensive to game it. 00:03:37.420 --> 00:03:39.740 Well, the future is at stake, right? 00:03:40.150 --> 00:03:41.730 The future of Bitcoin is at stake. 00:03:42.060 --> 00:03:44.180 Okay, but I'm glad somebody did a coin. 00:03:44.680 --> 00:03:49.080 There's been a couple of [unclear] by now, so we'll have to see. This is not what 00:03:49.080 --> 00:03:50.020 our episode is about. 00:03:50.260 --> 00:03:50.860 That's right. 00:03:50.960 --> 00:03:56.260 Our episode, this episode, episode 34, I think, is about Erlay. 00:03:56.480 --> 00:03:56.780 Erlay. 00:03:57.900 --> 00:04:03.680 So Erlay is a project. I think it was started at the University of 00:04:03.680 --> 00:04:09.000 British Columbia, or at least University of British Columbia researchers. Gleb 00:04:09.000 --> 00:04:12.380 Naumenko, Alexandra Fedorova, and Ivan 00:04:12.380 --> 00:04:17.360 Beschastnikh were working on it, as well as 00:04:17.360 --> 00:04:20.840 Blockstream's Pieter Wuille and Greg Maxwell. 00:04:21.220 --> 00:04:23.100 Yeah, Greg Maxwell is a Blockstream veteran. 00:04:24.360 --> 00:04:28.220 Yeah, well, when the project started, maybe he was still there. I'm not 00:04:28.220 --> 00:04:28.700 actually... 00:04:28.700 --> 00:04:32.920 No, he uses his personal email, so he might have been after. Okay. 00:04:33.260 --> 00:04:35.160 So, yeah, Erlay, it's... 00:04:36.440 --> 00:04:42.080 The problem it solves, so the problem, Sjors, is that nodes 00:04:42.080 --> 00:04:43.100 use bandwidth. 00:04:43.400 --> 00:04:44.280 Lots of bandwidth. 00:04:44.660 --> 00:04:50.160 Yes, and this is a problem because we want people to be able to run full nodes. 00:04:50.680 --> 00:04:56.640 And if full nodes use bandwidth and bandwidth costs money, the 00:04:56.640 --> 00:05:00.920 more bandwidth means it's more expensive to run a full node, which means fewer 00:05:00.920 --> 00:05:05.910 people will run full nodes or at least they'll be incentivized not to. It would 00:05:05.910 --> 00:05:10.370 be good if we could reduce the cost of running a full node. 00:05:11.010 --> 00:05:11.650 That's right. 00:05:11.830 --> 00:05:16.870 So it would be good if we could find ways to make it cheaper to run full nodes, 00:05:16.890 --> 00:05:20.610 which means if we could find ways to reduce bandwidth use. 00:05:20.830 --> 00:05:25.830 That's right. And we previously talked about downloading the blockchain as a 00:05:25.830 --> 00:05:31.150 source of bandwidth use. And we talked about some ways to make that smarter. But 00:05:31.150 --> 00:05:35.530 now we're going to talk about basically the transactions that are not yet in a 00:05:35.530 --> 00:05:36.510 block, the mempool. 00:05:36.670 --> 00:05:40.810 Yes. So I want to finish the benefits, basically, or the problem we're solving. 00:05:41.090 --> 00:05:45.570 So part one is it would be good if we could reduce bandwidth. 00:05:47.210 --> 00:05:52.590 Or if people choose to keep using the amount of bandwidth they're currently 00:05:52.590 --> 00:05:57.730 using, if we could further optimize the efficiency there, then we could make 00:05:57.730 --> 00:06:01.010 sure… then we could have nodes connect to more other nodes. 00:06:01.010 --> 00:06:01.630 Yes. 00:06:01.630 --> 00:06:07.630 Which would in turn benefit network robustness. It would counter certain types 00:06:07.630 --> 00:06:09.770 of attacks like eclipse attacks. 00:06:09.770 --> 00:06:13.750 Yeah, because we talked about eclipse attacks in earlier episodes and one of the 00:06:13.750 --> 00:06:18.130 solutions we already mentioned is well, just connect to more peers, and there is 00:06:18.130 --> 00:06:20.810 a big downside to that which we'll explain then I guess in a bit. 00:06:21.320 --> 00:06:21.780 Yeah. 00:06:21.900 --> 00:06:22.920 In terms of bandwidth use. 00:06:23.060 --> 00:06:27.320 Yeah. So if we could optimize bandwidth use, that means people can either run a 00:06:27.320 --> 00:06:31.980 full node more cheaply or they can connect two more nodes, which counter certain 00:06:31.980 --> 00:06:33.460 types of [unclear] or bit of both. 00:06:33.920 --> 00:06:34.020 Yeah. 00:06:34.140 --> 00:06:39.320 That's what we're trying to do is reduce bandwidth use. So you already mentioned 00:06:39.320 --> 00:06:45.060 this. There's basically two main things that cause bandwidth. One of them 00:06:45.060 --> 00:06:46.260 is: 00:06:47.540 --> 00:06:51.780 forwarding… receiving and forwarding blocks blocks… themselves, and this is what 00:06:51.780 --> 00:06:57.180 the blockchain consists of. And the other thing is receiving and forwarding 00:06:57.530 --> 00:06:58.850 transactions. 00:06:58.850 --> 00:07:01.630 That's right, before they are in the block. 00:07:01.630 --> 00:07:07.490 Yeah. So, yeah, this is how transactions find their way over 00:07:07.490 --> 00:07:12.790 a network, which ultimately is how they find their way to miners so they know 00:07:12.790 --> 00:07:14.570 which transactions they can include in blocks. 00:07:14.790 --> 00:07:18.050 Yeah, so every node has a thing called the mempool, which is where they keep 00:07:18.050 --> 00:07:21.690 track of transactions that aren't in a block yet, and they relay those to their 00:07:21.690 --> 00:07:25.840 peers. And you might say well, why… why would you do that? Well, there's some 00:07:25.840 --> 00:07:29.780 selfish interest, as in you want to know as soon as somebody is about to send you 00:07:29.780 --> 00:07:33.360 a transaction. You want to know as soon as somebody is about to cheat on you on 00:07:33.360 --> 00:07:37.180 Lightning. So it's nice to know that these transactions might start happening 00:07:37.180 --> 00:07:41.420 before they're in a block. But there's also an altruistic reason, like if nobody 00:07:41.420 --> 00:07:45.360 did this, then transactions would not get the miners because you'd have to know 00:07:45.360 --> 00:07:49.980 which nodes are the miners and send it directly to them. And so, especially 00:07:49.980 --> 00:07:55.000 because it's altruistic, you want to make it cheap or get a lot of value out of it. 00:07:55.340 --> 00:08:01.280 Right. So, receiving and sending transactions over the network. 00:08:01.720 --> 00:08:05.520 Not the blocks, the transactions. How does this actually… actually work on the 00:08:05.520 --> 00:08:06.200 technical level? 00:08:06.800 --> 00:08:08.680 Well, basically you just scream. 00:08:10.020 --> 00:08:13.710 That's kind of what it boils down to. I mean, you… you hear about a transaction. 00:08:13.860 --> 00:08:16.840 It's like, oh my God, everybody, did you know about this transaction? So 00:08:16.840 --> 00:08:21.170 literally, you know, you might be connected to I don't know, eight… eight peers 00:08:21.170 --> 00:08:26.610 outbound or even more inbound. And if you hear it from your first peer you will 00:08:26.610 --> 00:08:31.080 tell… tell all your other peers about it. And this is called flooding. So 00:08:31.080 --> 00:08:35.640 everybody just tells, gossips the transaction to as many nodes as they can. This 00:08:35.640 --> 00:08:39.060 uses an enormous amount of bandwidth, but it's very robust. Like it's very likely 00:08:39.060 --> 00:08:41.880 for a transaction to make it through and it will make it through very fast. 00:08:42.220 --> 00:08:47.180 Yeah, well, it's a little bit more nuanced than that, I think, right? Because you 00:08:47.180 --> 00:08:50.240 send transaction IDs first. 00:08:50.840 --> 00:08:53.840 Right, so there is some optimizations because what I just described would be 00:08:53.840 --> 00:08:56.100 sending the whole transaction. That would use a lot of bandwidth. 00:08:57.620 --> 00:09:02.700 But what you could do instead and what nodes actually do instead is sending short 00:09:02.700 --> 00:09:07.200 IDs, which is just a very short hash of the transaction. Not even the normal 00:09:07.200 --> 00:09:11.440 transaction ID, but something even smaller. And then when a node receives those, 00:09:11.700 --> 00:09:15.380 they can say, okay, I don't know about these ones. Tell me more. And then you 00:09:15.380 --> 00:09:18.440 give the whole transaction. So there's some back and forth, and this saves 00:09:18.440 --> 00:09:23.940 bandwidth, but it's a one-off saving. So maybe it reduces the total bandwidth by 00:09:23.940 --> 00:09:26.130 a factor of four. But that's it. 00:09:26.470 --> 00:09:32.350 Right. To make this very explicit, what happens is I receive a transaction 00:09:32.350 --> 00:09:38.350 ID or a short version of a transaction ID, which is a hash of a transaction 00:09:38.350 --> 00:09:42.930 and then I guess an even shorter version of that. I check this against all of the 00:09:42.930 --> 00:09:48.270 transactions I have in my mempool. If I don't have it yet, then I get back to the 00:09:48.270 --> 00:09:52.410 nodes that send me the ID and I tell them, hey, send me this whole transaction. I 00:09:52.410 --> 00:09:56.590 haven't seen this yet. This node sends me the whole transaction. Now I turn to 00:09:56.590 --> 00:10:02.470 all my other peers and I send them this ID. And then some of these peers will 00:10:02.470 --> 00:10:06.190 get back to me and tell me I don't have this transaction either. Send it to me as 00:10:06.190 --> 00:10:10.850 well please. Yeah, and that's how it's forwarded. Or if they have it already then 00:10:10.850 --> 00:10:14.350 I'm not going to send them the whole transaction. I'm just you know, I send them 00:10:14.350 --> 00:10:20.250 the ID. They checked it, they already have it, so we're good. Yeah, um, now 00:10:20.380 --> 00:10:26.330 what happens is that this last example where I send out an ID and my peer 00:10:26.330 --> 00:10:30.750 already has that transaction that actually happens a lot, because you know, they 00:10:30.750 --> 00:10:34.330 are connected to so many other peers as well, and odds are they already got it 00:10:34.330 --> 00:10:40.210 from someone else. So it happens a lot, that these transaction IDs are basically 00:10:40.210 --> 00:10:46.040 sent for you know, for nothing. They're… they already had the transaction. So 00:10:46.040 --> 00:10:51.120 this is in a way wasted bandwidth. I'm sending this transaction ID to them, 00:10:51.120 --> 00:10:54.240 they're receiving it, but they already had the whole transaction. So I'm sending 00:10:54.240 --> 00:10:55.520 the ID for no good reason. 00:10:55.520 --> 00:10:59.660 Yeah, and it's good to realize that it's kind of impossible… to at least naively 00:10:59.660 --> 00:11:03.660 impossible, to prevent that waste. But we can get into how much of that waste it 00:11:03.660 --> 00:11:07.960 is, but compared to the most ideal scenario where ideal, like a theoretical ideal 00:11:07.960 --> 00:11:13.610 scenario which is bad for decentralization reasons, but… If everybody just 00:11:13.610 --> 00:11:17.270 downloaded the transactions from a central website, well, that would be the most 00:11:17.270 --> 00:11:20.630 efficient way to do it in terms of data usage. But of course, we don't want to 00:11:20.630 --> 00:11:21.430 have a central website. 00:11:22.510 --> 00:11:27.690 Right. Yeah, the numbers are, I 00:11:28.390 --> 00:11:33.850 think, more than half of all bandwidth that a node is using are these transaction 00:11:33.850 --> 00:11:38.570 IDs, sharing these transaction IDs. And then if they run the numbers at some 00:11:38.570 --> 00:11:44.480 point, and I think about 44% of a total bandwidth use of a 00:11:44.480 --> 00:11:48.460 node is basically waste… Are these transaction IDs that… 00:11:48.460 --> 00:11:49.740 Are telling people what they already know. 00:11:50.060 --> 00:11:50.600 Exactly. 00:11:51.040 --> 00:11:51.160 Okay. 00:11:51.380 --> 00:11:55.780 So this 44%, that's what we're going to try to bring down with Erlay. 00:11:55.980 --> 00:11:56.460 That's right. 00:11:56.460 --> 00:12:01.400 That's what Erlay tries to bring down. Now, Erlay, in order to bring that down, 00:12:01.540 --> 00:12:04.960 it uses something called Minisketch, right? 00:12:05.220 --> 00:12:09.820 Yeah, it basically does two things, I guess, two general things. One is it still 00:12:09.820 --> 00:12:13.260 uses this flooding that we just described, and the other is it uses Minisketch. 00:12:13.400 --> 00:12:14.980 Right. So what is Minisketch? 00:12:15.140 --> 00:12:19.460 Yeah, the flooding is reduced, so it's only flooding now between publicly 00:12:19.460 --> 00:12:23.610 reachable nodes. And the general idea is that some nodes can be reached from the 00:12:23.610 --> 00:12:27.330 internet. They, you know, [unclear] is known, and other nodes are probably behind 00:12:27.330 --> 00:12:32.170 a firewall or just they have a privacy setting on and they're not reachable. But 00:12:32.170 --> 00:12:37.490 the idea is that every node that is… every node that is not reachable will 00:12:37.490 --> 00:12:40.750 connect to a node that is reachable, or almost everyone, unless you do it 00:12:40.750 --> 00:12:43.860 manually, right? Because otherwise, how do you connect to the rest of the 00:12:43.860 --> 00:12:46.960 network? So then the idea is that as long as all these reachable nodes… 00:12:48.340 --> 00:12:53.740 Have like, flood a lot between each other, then at least all the unreachable 00:12:53.740 --> 00:12:57.260 nodes are just one hop away from all the transaction data. So that's sort of the 00:12:57.260 --> 00:13:00.580 first step where it gets a little bit, you know, where you reduce the flooding to 00:13:00.580 --> 00:13:05.140 a smaller group of people. And then the second thing you do is, and this is the 00:13:05.140 --> 00:13:06.860 cool part, is the Minisketch. 00:13:08.000 --> 00:13:09.480 Right. So what's Minisketch? 00:13:10.180 --> 00:13:13.640 Okay. So the goal of Minisketch is to do set reconciliation. 00:13:14.300 --> 00:13:15.940 What is set reconciliation? 00:13:16.460 --> 00:13:21.550 Right, So a set is basically just a bag of stuff. 00:13:22.130 --> 00:13:25.610 In this case, the contents of your mempool. So the list of all your transactions, 00:13:25.630 --> 00:13:29.990 that's a set. Or the list of all the short IDs of your transactions is a set or 00:13:29.990 --> 00:13:35.970 whatever. And I have a mempool. So I have a set and 00:13:35.970 --> 00:13:40.130 you have a mempool. So you have a set. And then the question is, what is the 00:13:40.130 --> 00:13:43.150 difference between these sets? What are the transactions that I have that you 00:13:43.150 --> 00:13:45.510 don't have and that you have that I don't have? And that's probably just a 00:13:45.510 --> 00:13:50.500 fraction of the mempool. So that challenge in computer science is just called set 00:13:50.500 --> 00:13:54.160 reconciliation, trying to find out what the difference is and then trying for 00:13:54.160 --> 00:13:55.840 both of us to get the same set eventually. 00:13:56.020 --> 00:13:56.340 Right. 00:13:56.480 --> 00:13:58.360 Sending the least amount of data over and back and forth. 00:13:58.440 --> 00:14:04.000 So one way we could do that is you just send all of the transactions you have in 00:14:04.000 --> 00:14:09.680 your mempool to me. I compare all of your transactions to all of my transactions. 00:14:10.100 --> 00:14:14.360 I can easily tell the difference and send you the transactions that you didn't 00:14:14.360 --> 00:14:18.050 have yet. Keep the transactions from yours that I didn't have, and now the sets 00:14:18.050 --> 00:14:19.890 are reconciled. 00:14:19.950 --> 00:14:23.210 That is one way to do it. That is worse than what we just described with flooding. 00:14:23.410 --> 00:14:29.090 Yes, this is a very resource-intensive thing to do. So... We're using something 00:14:29.090 --> 00:14:32.870 more clever than this. But this is the general principle. We're just using 00:14:32.870 --> 00:14:35.430 something mathematically more clever. 00:14:35.750 --> 00:14:41.190 Exactly. So the mathematical clever thing is this. You take your... And this is 00:14:41.190 --> 00:14:44.970 where we're going to get extremely hand-wavy because I do not actually know or 00:14:44.970 --> 00:14:46.550 understand the moon math involved. 00:14:46.750 --> 00:14:48.070 God knows I don't either. 00:14:48.490 --> 00:14:53.660 No. That's okay, though. So the idea is I take my mempool, 00:14:53.900 --> 00:14:59.600 the set, and I do some math on it. And the end result is a little, maybe, 00:14:59.780 --> 00:15:05.460 I don't know, one kilobyte object or two kilobyte or whatever. Some small 00:15:05.460 --> 00:15:09.520 object compared to the rest of the mempool. And you do the same type of operation 00:15:09.520 --> 00:15:15.230 and you end up with maybe one kilobyte object. And now I send you my one kilobyte 00:15:15.230 --> 00:15:19.510 object. This is called the sketch. So I'm sending you my sketch. And that's just 00:15:19.510 --> 00:15:24.090 a tiny thing. You receive the sketch. And now the math says that if the 00:15:24.090 --> 00:15:27.750 difference between our two mempools was actually less than the size of the 00:15:27.750 --> 00:15:33.390 sketch, so if that was true, then you can actually figure out 00:15:33.390 --> 00:15:38.560 exactly which transactions are missing on either side. Only then. So if it… if 00:15:38.560 --> 00:15:41.780 the difference is bigger then you get gibberish. You don't know anything. But if 00:15:41.780 --> 00:15:45.780 the difference is the same or smaller, you can actually reconstruct which 00:15:45.780 --> 00:15:49.100 transactions I am missing and which transaction you're missing. And then the 00:15:49.100 --> 00:15:52.720 procedure is pretty simple, right? Your node will just give me the transactions 00:15:52.720 --> 00:15:57.240 that it knows I need. And it will ask for the transactions that it needs. 00:15:57.420 --> 00:16:02.760 Right. So for some absurd reason, we have completely different mempools, 00:16:02.900 --> 00:16:05.440 then this won't work very well? 00:16:05.740 --> 00:16:08.920 No. And the good thing, of course, about the mempool is that because you're 00:16:08.920 --> 00:16:14.310 syncing it all the time… And because there are rules about highest fee things are 00:16:14.310 --> 00:16:18.850 more important, it's actually fairly predictable what the mempool of other people 00:16:18.850 --> 00:16:22.050 are going to look like. So for the most part, it's going to be the same. So then 00:16:22.050 --> 00:16:26.590 it's just a matter of finding the right parameters to use with the sketch. How 00:16:26.590 --> 00:16:29.830 big do you want to make the sketches so that most of the time people will 00:16:29.830 --> 00:16:34.410 actually find the difference, but not so big that it just weighs more bandwidth 00:16:34.410 --> 00:16:38.390 than the flooding protocol. And that's sort of what the paper went into with simulations. 00:16:39.070 --> 00:16:44.490 Yeah, so if it's close enough, then I can figure out which transactions are the 00:16:44.490 --> 00:16:47.790 difference, and we can reconcile just these transactions. 00:16:48.230 --> 00:16:48.330 Yeah. 00:16:48.810 --> 00:16:53.890 So without getting into the moon math specifically, I know 00:16:53.890 --> 00:16:58.590 there's been some other examples where this kind of math has been used. 00:16:58.850 --> 00:17:02.930 Yeah, so it's interesting, and I only learned this today, maybe wrong on some of 00:17:02.930 --> 00:17:07.780 the stuff, but it refers to something called... What was it? Fuzzy [unclear], I 00:17:07.780 --> 00:17:08.300 think was the term. 00:17:08.480 --> 00:17:09.020 I think so. 00:17:10.400 --> 00:17:13.560 So it refers to an older paper from, I think, 2004, 2008, 00:17:13.380 --> 00:17:16.400 This predates… the trick predates Bitcoin, basically. 00:17:16.660 --> 00:17:20.900 Yeah, and I'm sure the general principle is even older. But the idea there is 00:17:20.900 --> 00:17:25.410 that, or the problem they were trying to solve was... For example, biometric 00:17:25.410 --> 00:17:26.070 identification. 00:17:27.050 --> 00:17:27.850 Like fingerprints. 00:17:28.150 --> 00:17:32.810 Yes. So if I want to go to my moon base and I want to enter the moon base, they 00:17:32.810 --> 00:17:33.490 want my fingerprint. 00:17:34.070 --> 00:17:34.670 Of course. 00:17:34.830 --> 00:17:36.390 But I don't want them to have a database. 00:17:36.630 --> 00:17:40.050 Everyone knows you can't get into your moon base without a fingerprint. 00:17:40.230 --> 00:17:43.310 Right. But I don't want them to have a database of my fingerprint. I don't want 00:17:43.310 --> 00:17:45.330 them to have a photo of my fingerprint. 00:17:46.680 --> 00:17:52.040 But they're going to need that, naively speaking, because when I put my finger on 00:17:52.040 --> 00:17:55.360 the little sensor, it's going to take a picture, and that picture is always going 00:17:55.360 --> 00:17:59.520 to be slightly different than what it was before. So they cannot just store, say, 00:17:59.600 --> 00:18:03.520 a hash of the image, right? They have to store the image itself and then look at 00:18:03.520 --> 00:18:05.820 it and say, well, this is so and so much different. 00:18:06.020 --> 00:18:09.300 The reason it's going to be slightly different than before is basically it's a 00:18:09.300 --> 00:18:13.880 photo, and even if you take a photo of the same object, it's going to be slightly 00:18:13.880 --> 00:18:19.400 tilted or slightly darker or some pixel is going to be different at least. So 00:18:19.400 --> 00:18:22.640 it's going to be similar but not literally exactly a copy. 00:18:22.860 --> 00:18:26.750 Right. Because every single pixel is slightly different. And the same really goes 00:18:26.750 --> 00:18:30.950 with normal passwords, right? One typo in your password and it just doesn't work anymore. 00:18:31.290 --> 00:18:35.930 Right. So it could work. We could use, you know, take a picture of your 00:18:35.930 --> 00:18:40.390 fingerprint and then make a new fingerprint and compare it to. However, the 00:18:40.390 --> 00:18:43.870 problem here is that we don't want a database full of fingerprints because people 00:18:43.870 --> 00:18:49.070 can steal the database and abuse it and rob banks and leave your fingerprints all 00:18:49.070 --> 00:18:49.590 over there. 00:18:49.790 --> 00:18:53.430 And there's another use case where this is an even bigger problem. Which is what 00:18:53.430 --> 00:18:57.490 if I want to put some Bitcoin on a private key that is generated by my 00:18:57.490 --> 00:19:01.130 fingerprint. So in this case, there is no database. There is just my fingerprint, 00:19:01.150 --> 00:19:06.400 and I want to construct a private key from that fingerprint. But if I do that, 00:19:06.860 --> 00:19:10.520 you know, take a picture on the device and then take the image and turn it into, 00:19:10.720 --> 00:19:16.260 you know, you can put the image literally on a COLDCARD and that's its entropy 00:19:16.260 --> 00:19:19.880 and it'll give you a set of private keys. And then if I repeat that, it'll give 00:19:19.880 --> 00:19:24.560 me a different set of private keys. So that'd be quite bad. And so it'd be nice, 00:19:24.660 --> 00:19:28.260 however, if you could do this in a way. And that's kind of what that original 00:19:28.260 --> 00:19:32.810 paper described, a way to do that. So it would take certain properties of the 00:19:32.810 --> 00:19:35.150 fingerprint or the iris scan, doesn't really matter what. 00:19:36.370 --> 00:19:39.470 And then it would create a sketch of your fingerprint. 00:19:39.770 --> 00:19:42.750 Right. That's where the term sketch comes from. 00:19:42.850 --> 00:19:42.950 Yeah. 00:19:43.270 --> 00:19:45.450 It's a mathematical sketch, basically. 00:19:45.870 --> 00:19:48.970 Yeah. A mathematical sketch of your fingerprint, which is not the same as a hash, 00:19:49.090 --> 00:19:52.870 but it is some sort of summary of it. But if you have that sketch, you cannot 00:19:52.870 --> 00:19:56.310 reconstruct a fingerprint. So it is similar to a hash and then you can't go back. 00:19:56.530 --> 00:20:01.450 It's a one-way function. But it is slightly more… it has a little bit more useful 00:20:01.450 --> 00:20:06.970 information than a hash does and it's very small. So what the Moonbase does, or 00:20:06.970 --> 00:20:07.610 what the 00:20:07.610 --> 00:20:09.400 iPhone… 00:20:08.730 --> 00:20:13.250 Yeah, what the iPhone would do, is it would store this sketch, and then when you 00:20:13.250 --> 00:20:16.830 reappear and you put your fingerprint on the sensor, it's now going to make a 00:20:16.830 --> 00:20:21.720 sketch of this new fingerprint. And then, because of what we just talked about, 00:20:22.000 --> 00:20:25.700 if those sketches are similar enough, you can actually reconstruct the 00:20:25.700 --> 00:20:30.480 difference. In other words, in the case of the Moonbase, you can say, hey, I can 00:20:30.480 --> 00:20:33.320 reconstruct the difference, therefore I think this difference is small enough. 00:20:33.440 --> 00:20:37.460 It's the real person. It's the real fingerprint. Or in the case of the private 00:20:37.460 --> 00:20:42.380 key, you can actually, because you stored a sketch of the original fingerprint, 00:20:43.200 --> 00:20:48.100 you can now, using the other fingerprint, essentially, your second fingerprint, 00:20:48.340 --> 00:20:52.620 and this original sketch, so you make a sketch of the new one, you can actually 00:20:52.620 --> 00:20:55.990 reconstruct the exact... sort of image that you would have had the first time 00:20:55.990 --> 00:20:59.490 around. And so you do get the same entropy. And so you can use your fingerprint 00:20:59.490 --> 00:21:04.140 to store your Bitcoin. Don't do this, but you could using this methodology. 00:21:04.500 --> 00:21:06.080 And this [unclear]… 00:21:05.390 --> 00:21:08.350 Yeah, that difference can also be used for mempool comparison. 00:21:09.490 --> 00:21:15.250 Yeah, so this trick for comparing fingerprints is the 00:21:15.250 --> 00:21:20.390 same mathematical trick that we're now using in the context of Bitcoin for set 00:21:20.390 --> 00:21:22.190 reconciliation 00:21:23.520 --> 00:21:24.520 in mempools. 00:21:24.520 --> 00:21:28.100 Which will make it more efficient to put your node on the moon. And or a full 00:21:28.100 --> 00:21:29.620 circle. Yeah exactly. 00:21:29.620 --> 00:21:35.120 Okay, how is this actually used in Bitcoin then? What actually 00:21:35.120 --> 00:21:40.970 happens? So, well, what's sort of the step-by-step process if 00:21:40.970 --> 00:21:42.710 we're using set reconciliation? 00:21:43.070 --> 00:21:46.530 Yeah, if this stuff were to be merged, right, in Bitcoin Core, well, the nice 00:21:46.530 --> 00:21:49.650 thing is it doesn't change any consensus rules, so it's just something people can 00:21:49.650 --> 00:21:50.870 use or they cannot use it. 00:21:52.290 --> 00:21:55.690 And you connect to peers, and if those peers support this way of handling 00:21:55.690 --> 00:22:00.200 things... Then, depending on whether they are public nodes or not, you would 00:22:00.200 --> 00:22:04.580 either do the original flooding or you would use the sketching. And you would 00:22:04.580 --> 00:22:08.780 basically exchange… you would keep your mempool synced by using these sketches. 00:22:09.340 --> 00:22:15.180 Right. So instead of constantly sharing every transaction ID you receive 00:22:15.180 --> 00:22:20.620 with all your peers, now you're also once in a while just sharing a sketch. 00:22:20.820 --> 00:22:25.560 And based on that… sharing the transactions that you don't share yet. 00:22:25.820 --> 00:22:29.440 Yeah. And this is so much more efficient that you can have lots and lots of peers 00:22:29.440 --> 00:22:33.460 with which you are exchanging these sketches far more than you could if you were 00:22:33.460 --> 00:22:34.360 using the flooding. 00:22:34.980 --> 00:22:35.260 Right. 00:22:35.280 --> 00:22:39.760 So you use flooding with a subset of your peers or not at all. And you use the 00:22:39.760 --> 00:22:43.640 sketches otherwise. And if the sketch somehow fails, there's a little fallback 00:22:43.640 --> 00:22:47.760 that's described in the protocol that says, well, if the sketch is too big, you 00:22:47.760 --> 00:22:52.600 can try something like half the sketch again and overlap those. And so you can do 00:22:52.600 --> 00:22:56.770 a second attempt if the difference is just a little bit bigger. And then if you 00:22:56.770 --> 00:23:00.890 give up, if it fails again because the difference was too big, great, you just 00:23:00.890 --> 00:23:04.600 fall back to the original flooding protocol. So that's kind of what it does. And 00:23:04.600 --> 00:23:06.580 there's a pull request on it. There's a BIP out there. 00:23:06.580 --> 00:23:11.300 Yeah, this is… an actual, because it sounds very hypothetical, but this is 00:23:11.300 --> 00:23:15.880 actually something that's being developed and that could be merged into Bitcoin 00:23:15.880 --> 00:23:16.320 Core? 00:23:17.080 --> 00:23:17.780 Right now. 00:23:18.420 --> 00:23:18.860 Soonish. 00:23:19.340 --> 00:23:23.820 I looked at the, only briefly looked at the pull request and it looks like most 00:23:23.820 --> 00:23:28.180 of the things are in there. But of course I haven't tested it or thoroughly 00:23:28.180 --> 00:23:31.660 reviewed it. So, but my guess is it'll happen. 00:23:33.320 --> 00:23:33.860 All right. 00:23:34.120 --> 00:23:37.020 Or maybe not if there's a huge problem, of course, but as far as I'm concerned, 00:23:37.100 --> 00:23:37.960 it sounds pretty good. 00:23:39.220 --> 00:23:41.400 Yeah. Clear so far. Anything else? 00:23:41.800 --> 00:23:43.320 I don't think so. That's all we got. 00:23:44.040 --> 00:23:44.540 All right. 00:23:44.860 --> 00:23:47.060 So thank you for listening to the Van Wirdum Sjorsnado. 00:23:47.540 --> 00:23:48.140 There you go.