WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:05.810 --> 00:00:09.550 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:09.810 --> 00:00:09.990 Hello. 00:00:10.730 --> 00:00:13.930 Van Wirdum Sjorsnado. That's right. Did I say it right this time? 00:00:14.070 --> 00:00:17.830 I don't know. We're not going to check again. This is take number three. Now 00:00:17.830 --> 00:00:20.650 you're going to ask me whether I rioted, and I'm going to say no. 00:00:23.140 --> 00:00:24.840 You're like psychic. 00:00:25.160 --> 00:00:25.700 Yes. 00:00:25.880 --> 00:00:30.600 You're able to predict the future. Okay, so let's skip all the rioting jokes and 00:00:30.600 --> 00:00:33.680 all the pronunciation jokes and get to it. 00:00:33.800 --> 00:00:34.220 Yes. 00:00:34.500 --> 00:00:35.600 What are we going to discuss? 00:00:35.820 --> 00:00:38.340 I think we're going to talk about compact block filters. 00:00:38.640 --> 00:00:40.660 Yes, aka neutrino. 00:00:41.140 --> 00:00:41.380 Yes. 00:00:41.780 --> 00:00:47.700 First of all, so yeah, these are a new type of filters for light clients. So 00:00:47.700 --> 00:00:51.980 first... Let's start at the beginning, Sjors. What are light clients? 00:00:52.280 --> 00:00:56.640 Yeah, and we should also caveat that by new type, we mean from 2018 or something. 00:00:56.840 --> 00:00:59.760 It's not brand new, but it's still fairly new. 00:00:59.920 --> 00:01:03.160 Yeah, we mentioned in the last episode that we were going to talk about that at some point. 00:01:03.260 --> 00:01:08.080 Yeah, we did, because we did a Bitcoin Core 21 episode, and it's one of the new 00:01:08.080 --> 00:01:09.940 features in Bitcoin Core 21. 00:01:10.540 --> 00:01:11.140 That's right. 00:01:11.260 --> 00:01:15.220 And now we're going to get more in depth about Neutrino. Okay. So what are light 00:01:15.220 --> 00:01:15.640 clients? 00:01:15.960 --> 00:01:19.560 So the idea of a light client is that you don't want to download the whole 00:01:19.560 --> 00:01:23.660 blockchain. And Satoshi made some remarks about that in the original white paper, 00:01:23.780 --> 00:01:27.410 how you could avoid downloading the entire blockchain. Maybe if you were on a 00:01:27.410 --> 00:01:28.030 mobile device. 00:01:28.030 --> 00:01:32.830 Yeah, you want to be able to use bitcoin that is send and receive bitcoins for 00:01:32.830 --> 00:01:37.230 example satoshis but you don't want to have to download the entire blockchain 00:01:37.230 --> 00:01:41.710 which you normally would have to do in order to know what the current state of 00:01:41.710 --> 00:01:47.210 balances of UTXOs is which you need to know in order to know if 00:01:47.210 --> 00:01:53.160 transactions are valid and so forth The downside is it takes about two days, I 00:01:53.160 --> 00:01:57.200 think, nowadays, depending on how fast your computer is, but something like that 00:01:57.200 --> 00:01:58.860 on a reasonably fast computer. 00:01:59.140 --> 00:02:00.820 Yeah, I think I can do it in five hours. 00:02:01.560 --> 00:02:06.480 Yeah, because you've got like a wizard's computer. But normal people would take 00:02:06.480 --> 00:02:10.760 like two days. But even on your phone, you couldn't do it in five hours. 00:02:10.960 --> 00:02:13.880 No, on a phone, it's horrible. It's days, if not weeks. 00:02:14.320 --> 00:02:17.920 Yeah, so that's where light clients come in. So what are light clients? 00:02:18.500 --> 00:02:22.780 Yeah, so of course there are different ways to do it. The very lightest of 00:02:22.780 --> 00:02:25.680 lightest clients would be a custodial wallet, but we don't want to talk about 00:02:25.680 --> 00:02:30.960 that. But here what we're talking about is something that uses SPV, so Simplified 00:02:30.960 --> 00:02:31.900 Payment Verification. 00:02:32.340 --> 00:02:36.480 Oh yeah, so custodial is one way to do it. The other way is to sort of connect a 00:02:36.480 --> 00:02:41.460 wallet to a full node, which you're running on some other device. But what we're 00:02:41.460 --> 00:02:46.990 going to discuss here is yet another... solution which yeah spv as you mentioned 00:02:46.990 --> 00:02:52.570 Yeah, so simplified payment verification as it says it is a simple way to verify 00:02:52.570 --> 00:02:56.250 payments and why do you care about that because the real one of the things you 00:02:56.250 --> 00:02:59.990 care about when using bitcoin is that you actually got the coins that you think 00:02:59.990 --> 00:03:03.990 you have Right, that may be something you want to verify and there's actually a 00:03:03.990 --> 00:03:09.470 way to do that which involves knowing the headers and the headers are 80 bytes 00:03:09.470 --> 00:03:11.290 each per block so it's pretty small. 00:03:11.290 --> 00:03:12.390 Yeah, the block headers. 00:03:12.390 --> 00:03:17.960 And then in addition to that a proof a Merkle proof that shows that this 00:03:17.960 --> 00:03:22.780 transaction is actually inside the block. So if you know what a transaction is 00:03:22.780 --> 00:03:27.120 and you know that it's in the block, then you know you've received it, assuming 00:03:27.120 --> 00:03:32.000 that the rest of the block was valid and nobody did any shenanigans with the 00:03:32.000 --> 00:03:32.620 history, etc. 00:03:33.120 --> 00:03:38.960 Yeah, so in a way, you're kind of trusting hash power. You're trusting... 00:03:39.250 --> 00:03:44.670 that whoever invested all this energy and hash power did so because 00:03:44.670 --> 00:03:50.560 it would be too expensive to do this while mining 00:03:50.560 --> 00:03:51.460 an invalid block. 00:03:51.700 --> 00:03:55.040 Exactly. So you're trusting other people to do the verification. The other thing 00:03:55.040 --> 00:03:59.680 is that somebody can prove that you did receive a transaction this way. They can 00:03:59.680 --> 00:04:03.740 give you that proof. For example, the person who paid you, but also the wallet 00:04:03.740 --> 00:04:07.260 has a way to fetch it, which we'll talk about. But it doesn't work the other way 00:04:07.260 --> 00:04:12.220 around. So just because nobody's giving you a proof doesn't mean that you did not 00:04:12.220 --> 00:04:15.560 receive the transaction. You cannot prove that a transaction does not exist. 00:04:16.390 --> 00:04:22.370 Right. So let's say I'm running an SPV client and someone told me 00:04:22.370 --> 00:04:28.030 they paid me, then I... wants to know if that's really true. So I would ask you, 00:04:28.190 --> 00:04:33.010 Sjors, who's running a full node. You could tell me I didn't receive anything, 00:04:33.030 --> 00:04:35.270 even if I did. I'm still trusting you in that way. 00:04:35.510 --> 00:04:39.810 Yeah. We can go into a little bit more detail about how that works. So the naive 00:04:39.810 --> 00:04:44.630 way would be, okay, if somebody makes a payment to you, then that person should 00:04:44.630 --> 00:04:48.870 send the proof. That's possible, but it's not very convenient. So what instead 00:04:48.870 --> 00:04:53.770 happens is something called bloom filters. And what your lightweight wallet does 00:04:53.770 --> 00:04:59.680 is it creates a filter which says, give me all the transactions that relate to 00:04:59.680 --> 00:05:04.460 this address. But it doesn't really say which address it is. But there's some 00:05:04.460 --> 00:05:09.540 magic math going on so that when a node sees a certain address, it'll know that 00:05:09.540 --> 00:05:14.390 it has to send you a signal. So for example, it would say, give me all the 00:05:14.390 --> 00:05:16.950 transactions in which an address starts with an A. 00:05:17.150 --> 00:05:17.490 Right. 00:05:17.710 --> 00:05:21.030 And that's not exactly how it works. It's mathematically more sophisticated than that. 00:05:21.150 --> 00:05:21.390 Sure. 00:05:21.550 --> 00:05:25.810 But you can understand intuitively what the privacy benefit of that is. Like, I'm 00:05:25.810 --> 00:05:28.790 not telling you that which address I have. I'm just telling you, tell me 00:05:28.790 --> 00:05:33.650 everything that has an A in it. And you can configure that. So you can say, well, 00:05:33.650 --> 00:05:37.810 give me every address with A, B, C, D, E, F, some more specific things. So you 00:05:37.810 --> 00:05:41.110 get only the transactions you care about. If you care a bit more about privacy, 00:05:41.310 --> 00:05:44.070 you ask for a bit more, but it comes at the cost of bandwidth. 00:05:45.050 --> 00:05:50.290 Yeah, so the thing is, your actual addresses are a subset of the addresses you're 00:05:50.290 --> 00:05:51.010 asking about. 00:05:51.410 --> 00:05:56.110 Exactly. So in practice, your light wallet sends a message to a full node 00:05:56.110 --> 00:06:00.070 somewhere on the network, one of its peers, and this full node will then keep an 00:06:00.070 --> 00:06:03.150 eye on that. As long as you're connected to it, it will keep an eye on those 00:06:03.150 --> 00:06:07.310 addresses and it will send you... It'll actually send you a block, but with only 00:06:07.310 --> 00:06:10.730 those transactions in it that match. And each of those transactions will have the 00:06:10.730 --> 00:06:12.810 correct proof that it actually belongs in the block. 00:06:12.990 --> 00:06:17.410 Right, which the light client is then able to check. So the light client checks, 00:06:17.670 --> 00:06:22.390 okay, is this actually the address I cared about or is this a false positive? Is 00:06:22.390 --> 00:06:27.690 the block valid as far as hash power goes? And then is the transaction valid, I 00:06:27.690 --> 00:06:32.330 guess. And if that all checks out, then the light client sort of knows. fairly 00:06:32.330 --> 00:06:35.770 sure that it has been paid even though they're still trusting hash power 00:06:35.770 --> 00:06:40.270 Yeah, so there's a couple of issues with this and we talked about one already 00:06:40.270 --> 00:06:45.130 Yeah, just to be clear in case any listeners are confused this is not what the 00:06:45.130 --> 00:06:49.870 rest of the episode is going to be about this is like a trick that exists has 00:06:49.870 --> 00:06:54.490 been existing for the past what is it eight years something like that yeah 00:06:54.490 --> 00:06:58.230 probably longer than that what we're actually going to discuss is improvements on 00:06:58.230 --> 00:07:03.560 this solution. Because there are problems with this solution, and that's what 00:07:03.560 --> 00:07:06.700 Sjors is going to explain now. What are the problems with this solution? 00:07:06.960 --> 00:07:12.020 Yeah, so one problem is privacy. And particularly, because you don't want to use 00:07:12.020 --> 00:07:16.520 too much data, there apparently are quite a few wallets out there that will use 00:07:16.520 --> 00:07:22.240 the lowest false positive rate possible. So you can say, okay, do I want 00:07:22.240 --> 00:07:26.340 lots of false positives? So lots of information about other addresses, so I have 00:07:26.340 --> 00:07:29.930 good privacy. but you can also set it very low and apparently they use a very low 00:07:29.930 --> 00:07:33.350 one, which means that you're really just telling the full node that you're 00:07:33.350 --> 00:07:35.930 talking to, okay, this is the address I care about. 00:07:36.290 --> 00:07:36.730 Yeah. 00:07:37.070 --> 00:07:40.730 And that's a problem because that full node you're talking to might be, I don't 00:07:40.730 --> 00:07:41.350 know, chain analysis. 00:07:42.190 --> 00:07:46.090 Yeah, and I think it's not just that. I think there's also some additional 00:07:46.090 --> 00:07:50.910 puzzling the full nodes can do. Like if he would be interested in this address, 00:07:50.950 --> 00:07:55.670 he wouldn't be asking about this or with change or something. I don't know the 00:07:55.670 --> 00:08:01.330 details. I just know that this solution, this SPV solution is broken privacy 00:08:01.330 --> 00:08:06.870 -wise. I think Nick Jonas broke it a long time ago. He works for Blockstream now. 00:08:07.050 --> 00:08:11.970 And since then, everyone... agrees that this is broken privacy-wise. If you're 00:08:11.970 --> 00:08:17.390 using SPV in this way, you're essentially giving away all of your addresses to a 00:08:17.390 --> 00:08:18.950 random node on the Bitcoin network. 00:08:19.270 --> 00:08:20.670 Okay, so that's also bad. 00:08:20.830 --> 00:08:25.470 Or several, probably even several nodes. You're just giving away your privacy. 00:08:25.670 --> 00:08:26.470 It's broken. It's broken. 00:08:26.750 --> 00:08:31.530 Yeah. The other problem is that it's pretty intense on the node that has to do 00:08:31.530 --> 00:08:35.450 this, that has to provide these filters. Because if you're running a full node, 00:08:35.750 --> 00:08:39.810 now some random node starts talking to you and says, hey, please give me updates 00:08:39.810 --> 00:08:40.570 about these addresses. 00:08:40.930 --> 00:08:41.130 Right. 00:08:41.250 --> 00:08:45.090 And so you need to do a bunch of CPU use for people and you're just doing it 00:08:45.090 --> 00:08:50.530 voluntarily. And it turns out that that's even exploitable. If you create a 00:08:50.530 --> 00:08:55.170 special filter, you can create a lot of CPU load for somebody, even though you 00:08:55.170 --> 00:08:58.450 don't actually care about those transactions. So you can, especially those 00:08:58.450 --> 00:09:00.710 Raspberry Pis, which just turn into steaming, you know. 00:09:01.130 --> 00:09:06.410 Yeah. So in this case, the light client, the SPV client is making the filter 00:09:06.410 --> 00:09:12.290 for the addresses it cares about plus false positives, gives this filter to a 00:09:12.290 --> 00:09:17.230 full node on a network, and then this full node has to decipher which addresses 00:09:17.230 --> 00:09:22.530 the light client is interested in, and this is costing the full node 00:09:22.530 --> 00:09:23.330 CPU power. 00:09:24.600 --> 00:09:29.540 So it's costly. And the full node isn't earning anything by it, unless it's a spy 00:09:29.540 --> 00:09:31.440 node, and then we're back to problem one. 00:09:31.800 --> 00:09:34.380 Well, yeah, and that creates a perverse incentive, of course, because for normal 00:09:34.380 --> 00:09:37.780 people, there is really no reason to do this other than altruism. But for spy 00:09:37.780 --> 00:09:41.660 nodes, there is a financial motive to do this. So, you know, guess who are 00:09:41.660 --> 00:09:46.680 serving this. So, okay, let's move on to a new approach that was produced, I 00:09:46.680 --> 00:09:49.880 believe, proposed around 2018, maybe 2019. 00:09:50.480 --> 00:09:51.980 By Laolu. 00:09:52.300 --> 00:09:53.460 Yep, roasbeef. 00:09:54.250 --> 00:09:56.150 Lightning Labs' CTO. 00:09:56.390 --> 00:10:01.290 Exactly. I cannot mimic his speaking face, but somebody could edit it. 00:10:01.290 --> 00:10:01.830 Nobody can. 00:10:02.170 --> 00:10:06.350 This is often referred to as Neutrino, but technically Neutrino is an 00:10:06.350 --> 00:10:07.650 implementation of that. 00:10:07.870 --> 00:10:09.010 Of the general idea. 00:10:09.190 --> 00:10:13.870 Yeah, of the idea of compact block filters. The BIPs you want to look for are BIP 00:10:13.870 --> 00:10:16.390 -157 and BIP-158. 00:10:16.750 --> 00:10:17.130 Okay. 00:10:19.290 --> 00:10:23.710 So, I think we should first talk about high-level what's going on and why it's 00:10:23.710 --> 00:10:27.950 good. And then I'll try to do a quick explainer on what it's actually doing at a 00:10:27.950 --> 00:10:30.530 more nitty-gritty technical level. Because it's kind of cool, I think. 00:10:30.650 --> 00:10:33.090 Sounds good to me. Start with the high-level stuff. 00:10:33.290 --> 00:10:37.830 So the high-level stuff, if you're running a full node, you're no longer getting 00:10:37.830 --> 00:10:41.730 custom filters from the peers that connect to you. There is only one filter. 00:10:42.110 --> 00:10:46.270 Basically, what you do as a full node is you process all your blocks and you 00:10:46.270 --> 00:10:51.390 create an index. For every block, there is a couple kilobytes of information that 00:10:51.390 --> 00:10:55.720 you need to keep track of. and you do that once and then peers can ask for it and 00:10:55.720 --> 00:10:58.660 you just give it to them. So every peer gets the same information from you. 00:10:58.780 --> 00:11:04.020 I think what you're trying to say is with the SPV solution we discussed a minute 00:11:04.020 --> 00:11:09.820 ago, the light client creates a filter that includes the addresses it 00:11:09.820 --> 00:11:15.820 cares about plus false positives. And in this neutrino solution or compact 00:11:15.820 --> 00:11:21.120 block side filters or whatever it was called officially, this is reversed. And 00:11:21.120 --> 00:11:23.420 the full node actually creates the filter. 00:11:24.190 --> 00:11:26.590 That's right. And the filter just covers everything. 00:11:26.810 --> 00:11:28.890 Right. Basically. Everything that's in the block. 00:11:29.110 --> 00:11:34.250 Well, every output script that's in the block. And for every input, the output 00:11:34.250 --> 00:11:37.690 script that corresponds to it, which would be in the previous block that it's spending from. 00:11:37.890 --> 00:11:43.310 So this means that... Any full node, especially now with Bitcoin Core 21, any 00:11:43.310 --> 00:11:45.030 full node can create a filter, right? 00:11:45.390 --> 00:11:45.970 That's right. 00:11:46.090 --> 00:11:48.590 And they would all be the same because they're all seeing the same block. 00:11:48.870 --> 00:11:49.310 Yes. 00:11:49.550 --> 00:11:49.710 Okay. 00:11:49.910 --> 00:11:54.530 And now on the client side, what you do is you connect to any peer and you say, 00:11:54.770 --> 00:11:55.530 give me the filters. 00:11:55.950 --> 00:11:56.110 Yeah. 00:11:56.390 --> 00:11:59.710 You know, you're not giving away any information when you're doing that other 00:11:59.710 --> 00:12:00.830 than that you're a light client. 00:12:01.320 --> 00:12:03.680 The light client just asks for the filter. 00:12:03.940 --> 00:12:08.220 Right, and in theory it could ask multiple peers and make sure that they get the 00:12:08.220 --> 00:12:08.700 same filter. 00:12:09.320 --> 00:12:11.780 Then what does the light client do with the filter? 00:12:11.940 --> 00:12:16.720 So what the light client is going to do is it's going to go through its own 00:12:16.720 --> 00:12:21.860 addresses and it's going to see, does the filter match any of those addresses? So 00:12:21.860 --> 00:12:26.600 basically you can see for every block you run your addresses through the filter 00:12:26.600 --> 00:12:31.900 and it'll say, yes, this block contains transactions pertaining to the filter. 00:12:32.380 --> 00:12:37.840 Or there are still false positives. So what you really, what the light clients 00:12:37.840 --> 00:12:42.780 really do is they use the filter, they have their addresses, they put their 00:12:42.780 --> 00:12:46.300 addresses through this filter or whatever they actually do technically. You're 00:12:46.300 --> 00:12:51.360 going to explain it in a minute. And then a computer is going to tell them... 00:12:51.870 --> 00:12:57.670 yes, there might be relevant transactions in this block. Or no, 00:12:57.870 --> 00:13:01.050 there are definitely no relevant transactions for you in this block. 00:13:01.150 --> 00:13:05.130 Yeah, and so this false positive story, as far as I know, is not because of 00:13:05.130 --> 00:13:07.770 privacy. It's just because math can't do better. 00:13:08.010 --> 00:13:08.330 Right. 00:13:08.630 --> 00:13:13.170 And this has to do with like, if you want less false positives, then the files 00:13:13.170 --> 00:13:15.550 that the node need to keep track of need to be bigger. 00:13:15.890 --> 00:13:16.310 Right. 00:13:16.390 --> 00:13:19.430 So if you make the filters really, really, really big, then you never get false 00:13:19.430 --> 00:13:23.490 positives. then you might as well download the whole block. right so when you so 00:13:23.490 --> 00:13:27.430 if, if the, if computer says no, if computer says no, there are definitely no 00:13:27.430 --> 00:13:32.930 relevant transactions in this block for you then the light client Just ignores 00:13:32.930 --> 00:13:33.350 the block. 00:13:33.650 --> 00:13:39.330 Exactly, which is, you can do that. Assuming the filters are not a lie, it should work. 00:13:39.670 --> 00:13:41.250 What if the computer says yes? 00:13:41.390 --> 00:13:43.510 If the computer says yes, you have to download this block. 00:13:43.770 --> 00:13:47.970 Then you download the full block. So even a light client in that case downloads, 00:13:48.410 --> 00:13:53.110 well, whatever it is, two megabytes of data, just downloads the whole block. And 00:13:53.110 --> 00:13:58.590 then searches in this block to see if there was actually a transaction pertaining 00:13:58.590 --> 00:14:00.610 to that light client in the block. 00:14:00.720 --> 00:14:06.640 Yeah, so if your wallet is tracking thousands of addresses, then maybe 00:14:06.640 --> 00:14:11.220 you have to download one in a hundred blocks as a false positive, even though you 00:14:11.220 --> 00:14:14.580 haven't done anything. Right. So this depends on how many addresses you're 00:14:14.580 --> 00:14:17.540 watching. You get a little bit more false positives. But yeah, you have to 00:14:17.540 --> 00:14:18.320 download a bunch of blocks. 00:14:19.200 --> 00:14:24.060 Yeah, so you actually have to download slightly more data, I guess, compared to 00:14:24.060 --> 00:14:27.340 the previous privacy-broken SPV solution. 00:14:27.440 --> 00:14:28.740 Yeah, but you get much better privacy. 00:14:28.940 --> 00:14:33.860 Yeah, because now sometimes you need to download a block. Even sometimes if 00:14:33.860 --> 00:14:37.160 there's a false positive, so sometimes you download a block for nothing, but 00:14:37.160 --> 00:14:41.180 sometimes you've got to download a block. but then you get much better privacy. 00:14:41.400 --> 00:14:46.080 Yeah, and you could even be smarter about it. You could request one block per 00:14:46.080 --> 00:14:51.980 peer so that the only thing each peer knows is that you may care 00:14:51.980 --> 00:14:56.560 about something in that block, which is not a lot of information. Maybe you fetch 00:14:56.560 --> 00:15:00.000 them over Tor if you want to be even better. So that's kind of nice privacy-wise, 00:15:00.080 --> 00:15:01.320 but yeah, it uses a bit more bandwidth. 00:15:01.640 --> 00:15:02.720 Is that a high-level part? 00:15:03.300 --> 00:15:09.040 No, so we can also talk about some of the downsides. So the biggest problem is 00:15:09.040 --> 00:15:14.080 that the filters can be fake, as in a node can just give you complete nonsense, 00:15:14.360 --> 00:15:20.020 and then you start asking for blocks. First of all, then it would match at the 00:15:20.020 --> 00:15:23.800 wrong block, so you wouldn't be able to find the blocks that pertain to you. Of 00:15:23.800 --> 00:15:28.380 course, at some point, maybe you can figure that out if you ask multiple peers 00:15:28.380 --> 00:15:32.860 for their filters, and then you start comparing which one is lying. But that's a 00:15:32.860 --> 00:15:36.880 can of worms. The good news is it is being used by a lot of the especially 00:15:36.880 --> 00:15:42.820 lightning mobile wallets. And they seem to work, but maybe we still live in this 00:15:42.820 --> 00:15:46.560 happy time. So I think we talked about that last time, right? Where now 00:15:46.560 --> 00:15:50.240 everybody's being nice to each other, but maybe one day people stop being nice to 00:15:50.240 --> 00:15:52.100 each other and then I don't know what's going to happen. 00:15:52.360 --> 00:15:56.480 Yeah, we spoke about it in the podcast, but I think in a different context, right? 00:15:56.800 --> 00:15:57.120 Yeah. 00:15:57.340 --> 00:16:02.780 Or not. Well, anyways, yeah. So one problem is that you're a light client. I'm a 00:16:02.780 --> 00:16:06.720 light client. I'm downloading this filter from you, Sjors, who's running a full 00:16:06.720 --> 00:16:12.120 node. And then I actually have no idea if this filter is actually a filter or 00:16:12.120 --> 00:16:14.300 just gibberish. Is that what you're telling me? 00:16:14.620 --> 00:16:18.780 Yeah, not just gibberish, but just wrong. Like it has the wrong transactions in 00:16:18.780 --> 00:16:20.240 it. It will match the wrong things. 00:16:20.420 --> 00:16:23.020 Right. And there's no way for me to tell the difference. 00:16:23.200 --> 00:16:27.560 No, and unfortunately, it's also not the case that if you download a block, you 00:16:27.560 --> 00:16:31.140 cannot recreate the filter. So the only way to create the filter is to download 00:16:31.140 --> 00:16:36.360 the entire blockchain. And the reason for that is that the filter contains not 00:16:36.360 --> 00:16:40.360 just the outputs, because the outputs you know, right? If you download a block, 00:16:40.400 --> 00:16:45.560 you know what outputs are in that block. But it also contains the outputs for 00:16:45.560 --> 00:16:51.470 every input. And so that refers to earlier blocks. So the only way 00:16:51.470 --> 00:16:56.910 to really check whether it's not lying would be to find a block and then 00:16:56.910 --> 00:17:02.390 make sure that you find all the blocks for those inputs and it would just be a 00:17:02.390 --> 00:17:04.130 mess. So that's unfortunate. 00:17:04.410 --> 00:17:09.270 This sounds like a very big downside. It sounds like if someone would want to 00:17:09.270 --> 00:17:11.750 attack these kind of light clients. 00:17:13.180 --> 00:17:17.880 Yeah, but then you have to maybe compare it to the earlier situation that we had 00:17:17.880 --> 00:17:22.360 with the Bloom filters. It's kind of also about lying by omission. That's really 00:17:22.360 --> 00:17:26.360 the problem, right? And it's sort of a DOS factor this time on the client, 00:17:26.400 --> 00:17:30.620 because the client could be having to download every single block. because it 00:17:30.620 --> 00:17:31.700 doesn't know which one to download. 00:17:32.180 --> 00:17:34.000 All right. Is that a high-level part? 00:17:34.200 --> 00:17:39.300 Yeah, I think in the long run, one of the thoughts is to turn that into a 00:17:39.300 --> 00:17:42.560 commitment into the block, but that itself is controversial, but that would at 00:17:42.560 --> 00:17:46.140 least solve this trust problem because if the filters are committed in a block, 00:17:46.640 --> 00:17:50.440 then you do know that they're correct. At least you're back to SPV proof. 00:17:50.600 --> 00:17:52.460 You're at least back to trusting the hash power. 00:17:52.720 --> 00:17:57.780 Yeah, so then you're at the same trust as you were with the Bloom filters in 00:17:57.780 --> 00:18:04.080 terms of trusting hash power. Okay, so let's maybe talk about how this works. 00:18:04.440 --> 00:18:06.000 Yeah, you want to get more technical? 00:18:06.380 --> 00:18:10.680 Yeah, so like I said, so here's the recipe. If you're serving these filters, what 00:18:10.680 --> 00:18:15.600 you do is you go through a block, for each block, you take all the output 00:18:15.600 --> 00:18:20.780 scripts, except op return, because that's not interesting, and you take all the, 00:18:20.960 --> 00:18:25.460 for every input, you take all the output scripts it refers to, and you just put 00:18:25.460 --> 00:18:29.980 those in a row. And now, for every item, you're going to hash it. there's a 00:18:29.980 --> 00:18:33.600 special hash function for it. We talked about hash functions, I think, in another 00:18:33.600 --> 00:18:37.240 episode. So now you have these hashes, which are just essentially all semi 00:18:37.240 --> 00:18:41.300 -random, right? Just looks like noise. And then you're going to... 00:18:41.300 --> 00:18:42.400 Looks like random numbers. 00:18:42.720 --> 00:18:46.380 Yes. They're deterministically random, so if you take an output script, you will 00:18:46.380 --> 00:18:49.540 get the same hash. And then you're going to sort those hashes. 00:18:51.180 --> 00:18:55.240 And you're going to calculate the difference between the hashes. Because hashes 00:18:55.240 --> 00:18:58.580 are just big numbers. So you can subtract. You sort them and then you subtract 00:18:58.580 --> 00:19:04.180 them. And it turns out that this is something you can compress with Golomb. I 00:19:04.180 --> 00:19:08.180 don't know how to pronounce it. Encoding. And this is just some mathematical 00:19:08.180 --> 00:19:12.220 trick that I don't understand. But it turns out that if you have a pattern like 00:19:12.220 --> 00:19:17.330 this. A bunch of sorted random things. You can compress it very efficiently. 00:19:18.140 --> 00:19:23.090 And so you do that, and now the client gets this compressed piece of data, 00:19:23.500 --> 00:19:28.300 and what it's going to do is it's going to look at the addresses that it is 00:19:28.300 --> 00:19:32.340 interested in, or the scripts that it is interested in, and it's going to hash 00:19:32.340 --> 00:19:38.220 its own scripts. And remember, the hashes were sorted, so now you 00:19:38.220 --> 00:19:43.000 can actually check the filter for the first hash, and then the second hash, and 00:19:43.000 --> 00:19:47.730 the third hash, etc., and see if you have a match. And then you can stop when 00:19:47.730 --> 00:19:52.810 your hash is higher, is a greater number than the last hash you checked. 00:19:54.310 --> 00:19:57.990 I don't understand that at all, but sounds interesting. 00:19:58.290 --> 00:20:01.770 Okay, well, that's fine. It wasn't the best explanation probably, but you can 00:20:01.770 --> 00:20:06.190 find it on the internet. But basically, it's kind of cool fancy math that lets 00:20:06.190 --> 00:20:09.010 you very efficiently communicate a lot of information. 00:20:09.460 --> 00:20:15.280 Love it. Right. Okay, so that was the high-level explanation. And then after 00:20:15.280 --> 00:20:19.800 that, the mathematical explanation, which I didn't understand, but maybe some of 00:20:19.800 --> 00:20:23.740 our listeners did. Probably only if they already understood it. Next question. 00:20:24.160 --> 00:20:29.900 You just mentioned embedding the filters into blocks. Why is this not 00:20:29.900 --> 00:20:32.320 already the case? To just put it bluntly. 00:20:32.480 --> 00:20:36.080 First of all, because it's a soft fork and we've talked about... you know, soft 00:20:36.080 --> 00:20:40.360 forks are the kind of things you want to be very careful with, but also because 00:20:40.360 --> 00:20:41.140 it's controversial. 00:20:41.460 --> 00:20:42.600 Why is it controversial? 00:20:43.000 --> 00:20:47.220 Well, probably for several reasons, but one reason would be how easy do you want 00:20:47.220 --> 00:20:50.340 to make it for people not to verify the whole chain? 00:20:50.580 --> 00:20:55.240 Right. Even if you're using this neutrino solution, just like the SPV solution, 00:20:55.340 --> 00:21:00.100 which we discussed at first, you're still not getting full security. You're 00:21:00.100 --> 00:21:04.540 still... trusting hash power as I've mentioned in both cases, so you're trusting 00:21:04.540 --> 00:21:09.470 that at least the majority of miners isn't lying to you, essentially. 00:21:09.970 --> 00:21:10.070 Yeah. 00:21:10.370 --> 00:21:15.090 Right? So then the question is, okay, we can make it very easy to run light 00:21:15.090 --> 00:21:19.930 clients, but do we actually want to make it very easy for people to run light 00:21:19.930 --> 00:21:24.370 clients because that way they're all going to trust the miners and maybe that's 00:21:24.370 --> 00:21:26.790 not such a good idea in the first place. 00:21:26.950 --> 00:21:31.010 Exactly. And there's kind of two forces where people are drawn to, right? On the 00:21:31.010 --> 00:21:33.930 one hand, you could say, well, if it's difficult to run a light client, maybe 00:21:33.930 --> 00:21:38.490 more people will run a full node on a good computer. But there's another 00:21:38.490 --> 00:21:42.930 attracting force that will just get people to use custodial wallets or some other 00:21:42.930 --> 00:21:43.390 thing. 00:21:43.690 --> 00:21:45.470 Yeah, or not Bitcoin at all. 00:21:45.970 --> 00:21:46.350 Exactly. 00:21:46.750 --> 00:21:46.870 Right. 00:21:47.130 --> 00:21:50.290 And it's hard to say, and in the long run, maybe it's different, right? Maybe in 00:21:50.290 --> 00:21:53.890 the short run, by supporting this, you get lots of mobile adoption of people who 00:21:53.890 --> 00:21:58.170 at least use Bitcoin, at least check the headers, rather than check absolutely 00:21:58.170 --> 00:22:03.390 nothing. But maybe on the very long run, that doesn't happen. Now, in the longer 00:22:03.390 --> 00:22:09.110 run, we have Moore's Law. So if the block size doesn't increase, and if 00:22:09.110 --> 00:22:12.510 networks and computers do get better, then maybe in a couple of decades, I think 00:22:12.510 --> 00:22:16.590 Luke Dashjr did a calculation on it, maybe in a couple of decades it becomes real 00:22:16.590 --> 00:22:18.110 practical to run this thing on your phone. 00:22:18.550 --> 00:22:23.150 Yeah, and I guess this would also assume Moore's law holding up, right? 00:22:23.530 --> 00:22:28.130 Yeah, or at least somewhat holds up. Otherwise it takes even longer. 00:22:28.510 --> 00:22:34.430 We could also decrease the block size limit, as Luke suggests. And that way 00:22:34.430 --> 00:22:39.070 it would be shorter. That way we could use full nodes on our phone sooner. 00:22:39.630 --> 00:22:44.830 Yeah, I don't know if that's worth having a giant civil war over though. And 00:22:44.830 --> 00:22:45.670 there was another thing. 00:22:45.770 --> 00:22:50.010 I think only Luke thinks that. Yeah. Well, not just Luke. There's a couple more 00:22:50.010 --> 00:22:52.070 people, but it's probably not going to happen. 00:22:52.110 --> 00:22:57.010 So this goes back to our Utreexo episode, where we discussed another way to 00:22:57.010 --> 00:23:01.910 verify blocks that takes less RAM. And one particular advantage of that approach 00:23:01.910 --> 00:23:07.410 is that you could sync a node on your computer and then just have a QR code on 00:23:07.410 --> 00:23:10.470 your computer because you trust your own computer. You scan it with your phone 00:23:10.470 --> 00:23:13.910 and boom, your node on your mobile phone is synced. So that gets rid of the 00:23:13.910 --> 00:23:18.790 initial sync problem. And this Utreexo technique allows you to work with very 00:23:18.790 --> 00:23:23.170 little RAM, which probably means that you can sync your phone on Wi-Fi and it'll 00:23:23.170 --> 00:23:26.890 be fast. And then maybe, you know, you use some of these light client techniques 00:23:26.890 --> 00:23:32.380 if you're outside doing something. So, you know, when you're outside, you make a 00:23:32.380 --> 00:23:35.660 payment or you receive a payment and you kind of trust it. But when you get home, 00:23:35.780 --> 00:23:37.460 you can immediately see if something went wrong. 00:23:37.940 --> 00:23:43.340 Yeah. So the episode is short. Neutrino compact side block filters. 00:23:43.960 --> 00:23:48.840 They're new type of light clients that offer more privacy. They are being used in 00:23:48.840 --> 00:23:52.820 lightning wallets, but they're not specifically for lightning wallets, right? Are 00:23:52.820 --> 00:23:55.660 they using any other? Are they using normal light wallets by now? 00:23:55.820 --> 00:23:56.380 I don't know. 00:23:56.770 --> 00:23:57.650 I don't think so. 00:23:57.750 --> 00:24:02.070 I haven't kept track of new normal light wallets, but I guess most of them are 00:24:02.070 --> 00:24:04.390 lightning wallets nowadays, the new wallets, aren't they? 00:24:05.970 --> 00:24:10.810 New wallets, sure, but I think Electrum, they would be interested to maybe 00:24:10.810 --> 00:24:13.270 implement it as well, but I don't think they have yet. 00:24:13.530 --> 00:24:16.210 That might be worth a brief mention too, right? The third solution that people 00:24:16.210 --> 00:24:17.730 are using is Electrum. 00:24:18.130 --> 00:24:21.770 Yeah, that is another sort of in-between solution. 00:24:21.990 --> 00:24:25.610 Yeah, as far as I know, Electrum will just say, here are my addresses, give me 00:24:25.610 --> 00:24:31.000 transactions. And then it will get SPV proofs. So you get less privacy than Bloom 00:24:31.000 --> 00:24:35.000 filters, but we already discussed that the privacy might be zero. But you do get 00:24:35.000 --> 00:24:38.800 the same security in terms of proving that these transactions are real. Right. 00:24:39.140 --> 00:24:42.000 And the same lying by omission and the same problem with potential spy nodes. 00:24:42.240 --> 00:24:44.140 Yeah, I guess that's all we've got here. 00:24:44.280 --> 00:24:44.900 I think so. 00:24:45.260 --> 00:24:48.500 In that case, thank you for listening to the Van Wirdum Sjorsnado. 00:24:49.040 --> 00:24:49.740 There you go.