WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.780 --> 00:00:25.220 Live from Utrecht, this is Bitcoin Explained. It's Sjors. 00:00:25.880 --> 00:00:26.780 We're back. 00:00:26.920 --> 00:00:32.700 We're back in beautiful, sunny Utrecht after I spent some time in Miami and 00:00:32.700 --> 00:00:37.820 Prague and you spent some time in Prague and more Prague. Is that right? 00:00:38.060 --> 00:00:38.640 Mostly Prague. 00:00:38.840 --> 00:00:39.900 You were in Prague for a while. 00:00:41.140 --> 00:00:46.740 That's where we recorded the previous episode. Of course, about Stratum V2. And 00:00:46.740 --> 00:00:51.820 now we're back in Utrecht. And we're going to talk about Bitcoin Core 25, 00:00:52.300 --> 00:00:57.000 which is the latest Bitcoin Core release. But it came out a couple of weeks ago. 00:00:57.720 --> 00:01:02.450 Because we were traveling, we didn't have time to record this episode yet. But 00:01:02.450 --> 00:01:07.890 dear listener, we won't disappoint you. Here we are with our episode on Bitcoin 00:01:07.890 --> 00:01:08.830 Core 25. 00:01:10.410 --> 00:01:11.670 Before we get there. 00:01:13.550 --> 00:01:16.710 It's time for the critical part of the show. 00:01:16.850 --> 00:01:21.050 I will be honest with you, Sjors. I am starting to regret doing the jingle 00:01:21.050 --> 00:01:25.400 myself. I do feel like I painted myself in the corner with this one. 00:01:26.150 --> 00:01:26.830 But [unclear]… 00:01:26.830 --> 00:01:32.750 Here we go. Sjors stacks sats. Sjors stacks sats. Sjors stacks sats. 00:01:33.310 --> 00:01:33.870 Yay. 00:01:35.510 --> 00:01:40.970 Okay, I guess I'll read one. We have 250 sats from a unit of Ack, 00:01:41.330 --> 00:01:45.350 which I would probably read as Proost, as in cheers, because it's two beer 00:01:45.350 --> 00:01:49.830 glasses. And then there's another one from Michael 00:01:49.830 --> 00:01:54.910 Matulev, Sjors stacks sats, without a music jingle. 00:01:56.080 --> 00:01:59.880 Um and MRMR 1750 sats. 00:01:59.880 --> 00:02:02.220 How do you know that was without the music jingle, Sjors? 00:02:02.220 --> 00:02:06.400 Because it doesn't have the music emoji. The last one did. 00:02:06.400 --> 00:02:08.720 Oh it actually did and you still didn't sing it? 00:02:08.720 --> 00:02:09.860 Yeah this one doesn't. 00:02:09.860 --> 00:02:11.680 Okay well what was the third one? 00:02:12.450 --> 00:02:14.530 Whatever let's move on. 00:02:14.530 --> 00:02:19.570 Sjors, do you still like this part of the episode? Because I don't think I've 00:02:19.570 --> 00:02:22.050 heard a single interesting message so far. 00:02:22.250 --> 00:02:25.110 Well, we could make the criteria a bit stricter that the message should actually 00:02:25.110 --> 00:02:26.550 be interesting before we do the segment. 00:02:27.790 --> 00:02:31.030 All right. Sjors stacks sats. 00:02:32.640 --> 00:02:36.200 Sjors, Bitcoin Core 25. Or 25.0. 00:02:36.200 --> 00:02:37.680 Speaking of not very interesting. 00:02:37.680 --> 00:02:42.320 Right I was just gonna say this doesn't strike me as a particular 00:02:42.320 --> 00:02:48.320 particularly spectacular release maybe as always I guess at this 00:02:48.320 --> 00:02:54.230 point most listeners will know but just For context, what does it 00:02:54.230 --> 00:02:56.170 mean that there is a new Bitcoin Core release? 00:02:56.350 --> 00:02:59.810 It means about six months went by since the last Bitcoin Core release. 00:03:00.190 --> 00:03:00.330 Right. 00:03:00.790 --> 00:03:06.790 So it's basically whatever makes it in by some date is what goes 00:03:06.790 --> 00:03:12.350 in. And then there's some time, maybe a month or two spent on fixing bugs, not 00:03:12.350 --> 00:03:15.700 changing anything, just fixing bugs. And then it's released. 00:03:15.900 --> 00:03:21.680 Right. So that's in contrast with some other types of software that will release 00:03:21.680 --> 00:03:27.100 a new version once they've included some kind of important new upgrade. Instead 00:03:27.100 --> 00:03:31.320 of that, Bitcoin Core just releases a new version every six months. So sometimes 00:03:31.320 --> 00:03:36.440 it's very interesting and sometimes not much happens in six months. That's really 00:03:36.440 --> 00:03:40.010 worth... talking about but we're still going to talk about it is that right? 00:03:40.010 --> 00:03:43.930 It also depends on your interest because if you look at the actual you know list 00:03:43.930 --> 00:03:47.990 of all the little commits that go in there there's a lot of stuff that's under 00:03:47.990 --> 00:03:53.410 the hood so if you find that stuff interesting um then there might actually be 00:03:53.410 --> 00:03:54.290 much more for you there. 00:03:54.290 --> 00:03:59.940 Sure I'm just approaching it from a podcast host perspective 00:03:59.940 --> 00:04:05.670 and what a average listener might find interesting I think this is 00:04:05.670 --> 00:04:09.650 not going to be the most spectacular episode but we're still going to do it Sjors. 00:04:09.650 --> 00:04:10.350 That's right. 00:04:10.350 --> 00:04:15.550 Okay so we highlighted a couple of upgrades that are at least kind of worth 00:04:15.550 --> 00:04:21.360 talking about and we're just going to do them in um in order 00:04:21.360 --> 00:04:27.060 of us having written them down in our own show notes. They're not in order of 00:04:27.060 --> 00:04:31.480 importance or in order of anything else right? I think that's right. Okay so 00:04:31.480 --> 00:04:32.400 number one: 00:04:33.940 --> 00:04:39.800 there is some kind of performance improvement when it comes to 00:04:40.590 --> 00:04:45.410 huge transaction loads and it has something to do with BRC-20 is that right? 00:04:45.410 --> 00:04:49.250 Yeah that's right. So what in more in general what we've seen in the last few 00:04:49.250 --> 00:04:54.850 months is the um the the inscriptions the Ordinals and then the 00:04:54.850 --> 00:05:00.010 BRC-20 hypes and also the Stamps hy— hype that we uh we talked about in earlier 00:05:00.010 --> 00:05:01.290 episodes it 00:05:01.290 --> 00:05:06.350 just yeah hang on so yeah we spoke about inscriptions Ordinals in a previous 00:05:06.350 --> 00:05:10.690 episode as well as Stamps. We have not spoken about BRC-20. 00:05:11.090 --> 00:05:16.330 No, BRC-20 is based on inscriptions. They are inscriptions. They're just 00:05:16.330 --> 00:05:20.090 inscriptions with a piece of JSON in it. And they are supposed to be smart 00:05:20.090 --> 00:05:24.930 contracts. I'm saying that with a very cynical face and scare quotes. They are 00:05:24.930 --> 00:05:26.810 not smarts and they're also not contracts. 00:05:27.670 --> 00:05:32.670 So this is also what I thought. But you're sure about it? They are just using 00:05:32.670 --> 00:05:33.410 inscriptions, right? 00:05:33.410 --> 00:05:33.570 Yeah. 00:05:33.670 --> 00:05:38.400 And then they do... It's kind of it's kind of like how Counterparty reinvented is 00:05:38.400 --> 00:05:39.020 that sort of? 00:05:39.020 --> 00:05:39.460 Yes. 00:05:39.460 --> 00:05:43.540 Because that's how it sounds it's just Counterparty reinvented more or less. 00:05:44.030 --> 00:05:44.470 Yes. 00:05:44.810 --> 00:05:49.770 Okay. Yep. Okay. And there's some kind of performance improvement in Bitcoin Core 00:05:49.770 --> 00:05:51.450 that has something to do with this. 00:05:51.650 --> 00:05:55.590 Yeah. So, I mean, generally speaking, what you see is people start using Bitcoin 00:05:55.590 --> 00:05:58.950 in very different ways. So the transactions look a little bit different than what 00:05:58.950 --> 00:06:02.770 you're used to. For example, you know, in the last episode or a few episodes ago, 00:06:02.890 --> 00:06:07.010 we talked about how invalid blocks were produced because people were putting 00:06:07.010 --> 00:06:10.410 multiple signatures in. Now, that wasn't a problem with Bitcoin Core. That was 00:06:10.410 --> 00:06:14.230 just a problem with the miner software. But software just gets stressed out and 00:06:14.230 --> 00:06:19.010 starts hitting weird corners. And so similarly, these BRC-20 transactions, they 00:06:19.010 --> 00:06:23.450 are atypically small. That's sort of one thing you would see about them. They're 00:06:23.450 --> 00:06:27.810 not the typical two-input-two-output transaction that you see normally. They're 00:06:27.810 --> 00:06:28.250 smaller. 00:06:28.490 --> 00:06:31.640 Why? What do they look like or what's the deal? 00:06:31.900 --> 00:06:34.980 I think, and I haven't looked at them in detail, they're probably just one input, 00:06:35.100 --> 00:06:38.620 one output, a lot of them. Because a lot of time what you do is you update the 00:06:38.620 --> 00:06:43.580 state of your smart contract. So you're saying, okay, my little fluffy image of a 00:06:43.580 --> 00:06:48.240 dolphin is now for sale. And that is just one JSON picture that you're uploading 00:06:48.240 --> 00:06:52.140 or one piece of JSON that you're uploading to the blockchain. You're not sending 00:06:52.140 --> 00:06:54.980 your coins anywhere. So you just probably just send the same coin to yourself. 00:06:55.580 --> 00:06:57.700 With this extra node on it right. 00:06:57.700 --> 00:07:02.000 So that so we don't have to re-explain how inscriptions work but you just put 00:07:02.000 --> 00:07:07.480 this data in the witness and most nodes wouldn't even look at it I guess. yeah 00:07:07.640 --> 00:07:11.940 and they're very small like you said because not much else is happening with the 00:07:11.940 --> 00:07:14.520 transaction. Yeah but this is the idea. Okay go on. 00:07:14.520 --> 00:07:18.500 But it does mean they're a little smaller than expected and then if you really 00:07:18.500 --> 00:07:22.220 look at how Bitcoin Core deals with things like the mempool how transactions are 00:07:22.800 --> 00:07:26.980 relayed to other nodes before they go in a block. There were some assumptions in 00:07:26.980 --> 00:07:29.820 there that were assuming that was happening at about seven transactions per 00:07:29.820 --> 00:07:34.240 second and you know with SegWit that increased a bit and for this type of usage 00:07:34.240 --> 00:07:35.680 it should be slightly higher too. 00:07:37.000 --> 00:07:40.660 Basically the new release contains some improvements to to handle these these 00:07:40.660 --> 00:07:44.240 higher numbers but I'm being very vague here so we should do another episode 00:07:44.240 --> 00:07:45.940 where we try to explain that in more detail. 00:07:45.940 --> 00:07:50.540 I mean probably when I understand it. Because it doesn't sound super interesting 00:07:50.540 --> 00:07:56.440 but basically what it comes down to if I understand you correctly is the 00:07:56.960 --> 00:08:01.680 Bitcoin Core software the Bitcoin Core code is sort of 00:08:02.600 --> 00:08:08.340 calibrated with certain assumptions in it of how Bitcoin would usually 00:08:08.340 --> 00:08:10.960 be used and then that software sort of 00:08:13.620 --> 00:08:17.940 knows, yeah, it's optimized for that situation. And now that situation kind of 00:08:17.940 --> 00:08:21.980 changed because of BRC-20 and inscriptions and all of that. And this new Bitcoin 00:08:21.980 --> 00:08:27.780 Core release kind of takes this new way of using Bitcoin into account with its 00:08:27.780 --> 00:08:29.240 assumptions in its code. 00:08:29.460 --> 00:08:32.720 Yeah, and I guess the bigger picture here is that, you know, in blocks, we have a 00:08:32.720 --> 00:08:36.120 very hard limit. You know, there's only so many megabytes that go into a block. 00:08:36.260 --> 00:08:39.740 So it's much easier to reason about sort of the worst case. But for the mempool, 00:08:39.900 --> 00:08:41.040 there are not really any rules. 00:08:42.240 --> 00:08:46.440 Because it's not really consensus, right? So it's a little bit more complicated 00:08:46.440 --> 00:08:49.940 to make code that handles all mempool scenarios ideally. 00:08:50.400 --> 00:08:55.780 Right, okay. Now let's make this as practical as we can make this. 00:08:56.100 --> 00:09:01.860 So I'm a casual Bitcoin Core user. What's the 00:09:01.860 --> 00:09:06.320 benefit for me when I download Bitcoin Core 25? How does it help me? 00:09:07.280 --> 00:09:11.720 Probably when there's another storm of these super small BRC-20 transactions, 00:09:12.120 --> 00:09:16.020 your node will be happier. And by happier, I just mean it's probably going to 00:09:16.020 --> 00:09:20.400 make your computer less hot, use less memory, stuff like that. 00:09:20.720 --> 00:09:21.420 Require less resources. 00:09:21.800 --> 00:09:21.900 Yeah. 00:09:22.770 --> 00:09:27.010 Okay, I like my computer cooler, so that's good. Next point, 00:09:29.550 --> 00:09:29.750 right? 00:09:30.130 --> 00:09:30.330 Yeah. 00:09:30.570 --> 00:09:36.530 Okay, so there's some update with Miniscripts. We've done a whole 00:09:36.530 --> 00:09:40.380 episode on Miniscripts. Do you remember what episode that was? 00:09:40.600 --> 00:09:41.300 I do not. 00:09:42.120 --> 00:09:47.850 Look it up. And then I think in a previous Bitcoin Core release episode, we also 00:09:47.850 --> 00:09:53.800 mentioned that something... Miniscript related was implemented but it wasn't 00:09:53.800 --> 00:09:57.260 quite there and it sounds like a new step has been made right? 00:09:57.260 --> 00:10:00.820 Yeah so when we described Miniscript several years ago I think it was one of the 00:10:00.820 --> 00:10:05.340 first episodes where Miniscript is just a way it's not a consensus change it's 00:10:05.340 --> 00:10:09.220 not a soft fork, it's just a way to write scripts in a in a sane way because 00:10:09.220 --> 00:10:13.840 writing scripts Bitcoin script by hand is a the best way to lose your money and 00:10:13.840 --> 00:10:17.860 using Miniscript basically allows you to write scripts in a safe way now Bitcoin 00:10:17.860 --> 00:10:23.070 Core added support for making a watch-only wallet. So that's a wallet that you 00:10:23.070 --> 00:10:27.350 can see your balance. You can create addresses. So you can use Miniscript and you 00:10:27.350 --> 00:10:31.690 can receive coins, but you couldn't spend it. So that's not ideal for most 00:10:31.690 --> 00:10:36.290 people. And so this new release does let you spend it. I'd still say it's pretty 00:10:36.290 --> 00:10:40.950 experimental. And there are some edge cases where you can actually not spend it. 00:10:41.960 --> 00:10:47.650 Okay, so maybe as a very... brief recap of Miniscript 00:10:47.650 --> 00:10:53.220 actually. So the thing here is that the Bitcoin protocol allows certain kind of 00:10:53.220 --> 00:10:57.520 basic smart contract functionalities. So it allows multisig, it allows time 00:10:57.520 --> 00:11:03.350 locks, it allows I don't know hash pre-images, it allows a bunch of things. And 00:11:03.350 --> 00:11:08.710 with Miniscript, it's actually very easy to implement these things in the smart 00:11:08.710 --> 00:11:13.590 contract way. So you can receive coins in a certain way. So for example, you can 00:11:13.590 --> 00:11:18.180 have a board of directors and a company and they can say... Three out of five 00:11:18.180 --> 00:11:22.080 have to agree or two out of five after a year, whatever. You can do that kind of 00:11:22.080 --> 00:11:26.060 stuff. And with Miniscript, you can implement that easily. Now with Bitcoin Core, 00:11:26.640 --> 00:11:30.740 okay, now is where I'm getting kind of lost. Because this is what the Bitcoin 00:11:30.740 --> 00:11:31.840 protocol allows. 00:11:32.320 --> 00:11:34.700 Yeah, nothing changed in the Bitcoin protocol for Miniscript. 00:11:34.880 --> 00:11:36.720 Right, so what is Bitcoin Core actually? 00:11:37.140 --> 00:11:41.160 Well, Bitcoin Core is really multiple things. So Bitcoin Core is the node, the 00:11:41.160 --> 00:11:44.520 thing that checks the blocks for validity. Nothing changed there. But Bitcoin 00:11:44.520 --> 00:11:49.340 Core is also a software package that has a wallet built into it. Now, anybody's 00:11:49.340 --> 00:11:53.400 free to build a wallet, there's nothing special about the Bitcoin Core wallet. In 00:11:53.400 --> 00:11:56.480 fact, it's probably not one of the most user-friendly wallets, but it is quite 00:11:56.480 --> 00:12:00.320 powerful. At least it's becoming quite powerful. I think that's a better way to 00:12:00.320 --> 00:12:05.500 say it, thanks to Miniscript. So this wallet is able to use Miniscript. 00:12:06.510 --> 00:12:09.870 But when you say, okay, you say use Miniscript. 00:12:10.070 --> 00:12:13.230 It means you can give it a piece of Miniscript and it understands how to create 00:12:13.230 --> 00:12:16.930 addresses, how to sign transactions using it, etc. 00:12:17.170 --> 00:12:22.510 Okay, but Miniscript is literally script. It's not—it's still something you code 00:12:22.510 --> 00:12:23.570 as a programmer, right? 00:12:23.770 --> 00:12:23.870 Yeah. 00:12:24.860 --> 00:12:30.340 So you give that code to the Bitcoin Core wallet. Okay, we're not talking about 00:12:30.340 --> 00:12:34.640 the GUI then. You have to go into the command line and you paste a piece of code 00:12:34.640 --> 00:12:37.120 there. And this is what Bitcoin Core will understand. 00:12:37.420 --> 00:12:40.780 Yeah, but basically, I mean, some people may have been used to pasting xpubs 00:12:40.780 --> 00:12:46.360 around. So it's basically Miniscript. The way it works in practice is just an 00:12:46.360 --> 00:12:50.400 xpub with a bunch of extra script around it saying what to do with the xpub. 00:12:50.540 --> 00:12:51.840 Okay, this is what you paste. 00:12:52.740 --> 00:12:55.480 Yeah, you paste it in the command line, but there's no reason this could not— 00:12:55.580 --> 00:12:59.100 this could be added to the user interface too. It's just that you'll have to paste 00:12:59.100 --> 00:13:02.560 something magical that you probably don't understand. So it's a bit dangerous. 00:13:02.840 --> 00:13:07.060 Okay. And so far, Bitcoin Core could understand it and you could receive the 00:13:07.060 --> 00:13:10.420 coins, but then they were just sitting there in your wallet and you couldn't 00:13:10.420 --> 00:13:11.220 actually spend them. 00:13:11.500 --> 00:13:11.620 Yeah. 00:13:12.200 --> 00:13:15.580 Yeah, it sounds like being able to spend them is a pretty good upgrade. 00:13:15.800 --> 00:13:18.700 It's one of the nicer features of Bitcoin, although it's good for inflation if 00:13:18.700 --> 00:13:19.620 people don't, you know. 00:13:21.190 --> 00:13:26.850 Okay, so I guess... Wait, but this is still 00:13:26.850 --> 00:13:29.410 sort of limited. It doesn't... 00:13:29.410 --> 00:13:32.790 Yeah, I think for the most cases that you've described it will work. You can 00:13:32.790 --> 00:13:36.290 create a PSBT because there's now two, I believe, two hardware models or maybe 00:13:36.290 --> 00:13:42.010 three. So the Ledger was first and then I believe it was COLDCARD 00:13:42.010 --> 00:13:46.540 or BitBox, one of those two, added support for Miniscript, which means you can 00:13:46.540 --> 00:13:51.300 make like a multisig wallet with three physically different devices with each 00:13:51.300 --> 00:13:56.700 having their own trade-offs. And in order to do that, you need PSBTs generally to 00:13:56.700 --> 00:14:00.600 move between these devices. But there are some limits to what you can do there. 00:14:00.740 --> 00:14:04.420 So there may be some obscure scripts that you can write them, you can receive 00:14:04.420 --> 00:14:07.800 coins on it, but you will not be able to send them to the hardware wallets using 00:14:07.800 --> 00:14:11.820 a PSBT. Some like edge case that if you know Miniscript, you'll probably 00:14:11.820 --> 00:14:13.280 understand the edge case. I don't. 00:14:13.650 --> 00:14:16.430 And also, it doesn't work with Taproot yet. 00:14:16.730 --> 00:14:20.290 Yeah, that's a bigger drawback, I would say. Miniscript was designed quite a 00:14:20.290 --> 00:14:26.290 while ago before Taproot. And it is initially designed for the use 00:14:26.290 --> 00:14:32.100 with SegWit, basically SegWit script. Actually, I think there's also 00:14:32.100 --> 00:14:36.600 a Miniscript standard for pre-SegWit script, I think. But at least it was 00:14:36.600 --> 00:14:41.360 designed for SegWit script. And so there has now been a recent modification to 00:14:41.360 --> 00:14:45.100 that proposal that also makes it work for Taproot script. Because most of the 00:14:45.100 --> 00:14:48.240 script is the same between SegWit and Taproot. Most are the same opcodes, so you 00:14:48.240 --> 00:14:53.730 can make signatures, etc. But there's a few subtle changes in Taproot. So that 00:14:53.730 --> 00:14:55.210 changes a few things about Miniscript. 00:14:55.390 --> 00:15:00.240 So is that... So that would be an upgrade in the future, potentially, I would assume. 00:15:00.520 --> 00:15:03.100 Yeah. And that's, again, that's one step at a time. So the first step would be 00:15:03.100 --> 00:15:08.960 that you can write Miniscript and then it'll generate, you know, a leaf, a 00:15:08.960 --> 00:15:12.560 script leaf in Taproot because you can put your individual scripts and individual 00:15:12.560 --> 00:15:18.140 leaves in the tree. But there's no way yet to decide how to most efficiently, 00:15:18.140 --> 00:15:22.420 you know, distribute your... your scripts between all the leaves so if you have 00:15:22.420 --> 00:15:25.860 like five different conditions do you want to make five leaves in Taproot or do 00:15:25.860 --> 00:15:29.260 you want to make one leaf that does two of them that sort of stuff there's 00:15:29.260 --> 00:15:30.820 nothing no tooling for that yet. 00:15:30.820 --> 00:15:33.160 Right okay. so 00:15:33.160 --> 00:15:34.040 Soon tm. 00:15:34.490 --> 00:15:40.350 Two weeks. So we've mentioned two improvements so far which had one 00:15:40.350 --> 00:15:44.870 was the transaction loads BRC-20 and then we now mentioned Miniscript and now 00:15:44.870 --> 00:15:48.490 we're getting to the third one and that's actually the last one already. 00:15:50.680 --> 00:15:52.300 Fast wallet rescan. 00:15:52.540 --> 00:15:54.960 Fast wallet rescan. Sjors, explain. 00:15:55.960 --> 00:16:01.300 So Bitcoin Core again has a wallet built into it. And let's say you first used 00:16:01.300 --> 00:16:06.870 that in 2012 and you received some Bitcoin. And then you were like, okay. Let me 00:16:06.870 --> 00:16:11.650 put this wallet on a USB stick put it in a vault somewhere physically so the 00:16:11.650 --> 00:16:16.350 whole wallet not just a backup codes just the actual file and remove it from my 00:16:16.350 --> 00:16:20.090 computer because I'm traveling around with it now your node just keeps updating 00:16:20.090 --> 00:16:24.210 keep syncing, keep syncing, keep syncing, and then now you come back and you you 00:16:24.210 --> 00:16:27.890 put the USB stick back into your computer maybe that's a bad idea if there's a 00:16:27.890 --> 00:16:33.820 lot of money on it but let's say you do and use Well, then your 00:16:33.820 --> 00:16:38.800 wallet is behind, in a sense, because the new transactions that happened since 00:16:38.800 --> 00:16:42.780 2012 would not be in that wallet file because it was in your vault. And your node 00:16:42.780 --> 00:16:46.440 doesn't know, it doesn't really track them either, not specifically. It just has 00:16:46.440 --> 00:16:51.460 all the blocks. So there's something called a rescan, which basically the wallet file... 00:16:51.460 --> 00:16:56.640 Wait, wait, wait, wait. So, because this is confusing. I think what you mean to 00:16:56.640 --> 00:17:02.480 say is you received coins on one wallet. And now after that, you 00:17:02.480 --> 00:17:07.740 started using a new wallet, right? When you say syncing, syncing, syncing, your 00:17:07.740 --> 00:17:09.920 node is not syncing based on that wallet anymore. 00:17:10.100 --> 00:17:12.640 Yeah, your node is still syncing. It's just storing all the blocks and checking 00:17:12.640 --> 00:17:17.400 the validity. But it's not keeping track of how that matters for your wallet. 00:17:17.540 --> 00:17:21.260 Right. So you basically reinstalled Bitcoin Core or something like that. You got 00:17:21.260 --> 00:17:22.700 a new computer, something like that, right? 00:17:22.740 --> 00:17:27.760 No, you can basically unload a wallet and then load it again. 00:17:28.210 --> 00:17:29.150 But in most— 00:17:29.150 --> 00:17:32.770 But I guess another scenario would be yes so so you are restoring you're 00:17:32.770 --> 00:17:37.230 reinstalling Bitcoin Core and you you're recovering your wallet and you're trying 00:17:37.230 --> 00:17:40.650 to see if there's any coins in that wallet and find the transactions and the only 00:17:40.650 --> 00:17:43.690 way to do that is to go through all the blocks and check for every block if 00:17:43.690 --> 00:17:47.130 there's something useful in that block and that just takes a long time could be 00:17:47.130 --> 00:17:48.390 several hours. 00:17:51.750 --> 00:17:53.310 That's not so bad. 00:17:53.310 --> 00:17:55.450 Computer. Okay it depends on your patience. 00:17:55.450 --> 00:17:58.010 I guess I guess we can do better than that. 00:17:58.680 --> 00:17:59.500 Yes, we can. 00:17:59.640 --> 00:18:00.480 So how do we do better? 00:18:00.780 --> 00:18:04.140 Yeah, so basically this is using the Neutrino filters that we did an earlier 00:18:04.140 --> 00:18:06.600 episode about, the compact block filters. 00:18:08.080 --> 00:18:13.020 Forgot the episode. Look for Bitcoin Explained Neutrino and you'll find it. But 00:18:13.020 --> 00:18:16.620 the idea there is that light wallets can use these filters to figure out which 00:18:16.620 --> 00:18:21.480 blocks they need to download. So instead of downloading all the blocks, a mobile 00:18:21.480 --> 00:18:26.300 wallet can say, okay, it can figure out by itself without revealing any private 00:18:26.300 --> 00:18:30.620 information to the outside world. Which blocks it it should download and in order 00:18:30.620 --> 00:18:34.100 to do that it needs to download something called these filters these filters are 00:18:34.100 --> 00:18:39.480 much smaller than normal blocks and so Bitcoin Core can create these filters and 00:18:39.480 --> 00:18:43.820 Now the wallet will take advantage of that because rather than scanning every 00:18:43.820 --> 00:18:48.220 block From the history from the last time you checked your wallet it now knows 00:18:48.220 --> 00:18:52.840 which blocks it needs to scan And so it'll scan fewer blocks, which is faster. 00:18:53.160 --> 00:18:59.100 Yes. Wait. So if I have a wallet.dat file on a USB stick, 00:18:59.120 --> 00:19:04.140 as we discussed, that's the example we're using. And I 00:19:04.140 --> 00:19:09.760 buy a new computer tomorrow and I sync Bitcoin Core and now I get the wallet.dat 00:19:09.760 --> 00:19:15.410 file. Somehow Bitcoin Core would know which blocks to download based on the wallet. 00:19:15.410 --> 00:19:20.550 So the wallet.dat contains the addresses that belong to your wallet. And so 00:19:20.550 --> 00:19:25.250 depending on how old it is, that's going to be somewhere between 2,000 and 8,000 00:19:25.250 --> 00:19:30.170 because it basically creates a cache of addresses. It knows these addresses. And 00:19:30.170 --> 00:19:34.510 yet using these filters, which Bitcoin Core will also have created, it's able to 00:19:34.510 --> 00:19:39.210 know which blocks are relevant and which blocks are not because these filters are 00:19:39.210 --> 00:19:40.810 like a compressed summary of the blocks. 00:19:42.620 --> 00:19:47.320 So then it looks at the filters and it says, okay, do my addresses, if I run my 00:19:47.320 --> 00:19:51.000 addresses to this filter, does it say yes or no? And if it says yes, I'm going to 00:19:51.000 --> 00:19:54.360 download the block and I'm going to check everything. Filters are not accurate. 00:19:54.880 --> 00:19:58.340 So it's possible that you might download 10 times more blocks than you really 00:19:58.340 --> 00:20:02.100 need, but you're not downloading them all. And in the case of Bitcoin Core, it's 00:20:02.100 --> 00:20:04.220 not even about downloading them. It's just about checking them. 00:20:05.620 --> 00:20:10.660 Well... Yes, so it doesn't work with a pruned node, right? You do need to have 00:20:10.660 --> 00:20:11.620 all the blocks available. 00:20:11.940 --> 00:20:15.100 Correct. At the moment, it does not work with a pruned node, but if you had these 00:20:15.100 --> 00:20:18.680 filters on your computer, but pruned blocks, you would be able to know which 00:20:18.680 --> 00:20:24.220 blocks to download again, which currently you can only do with some manual magic. 00:20:24.420 --> 00:20:28.060 So it is possible, actually, with a pruned node, but then you need a script. And 00:20:28.060 --> 00:20:33.840 basically, I've tried this myself, just to experiment with it. You can scan. 00:20:34.710 --> 00:20:38.190 I don't know if I tried this myself. I may not. No, I think I'm lying here. But 00:20:38.190 --> 00:20:42.650 in theory, it's possible to download all the blocks that you're missing and then 00:20:42.650 --> 00:20:45.290 scan it. But the wallet will [unclear] be very confused. 00:20:46.470 --> 00:20:50.250 Okay. Well, I don't understand how this works, but that's probably because I 00:20:50.250 --> 00:20:53.970 forgot how Neutrino works. So if I want to understand that, I would have to go 00:20:53.970 --> 00:20:55.670 back to our own episode and listen to that. 00:20:55.830 --> 00:20:56.210 Sounds good. 00:20:57.250 --> 00:21:00.570 Unless, Sjors, you want to try explaining this right now? 00:21:01.220 --> 00:21:02.540 You forgot how an Arduino works. 00:21:02.740 --> 00:21:03.580 I mean, I don't remember. 00:21:03.680 --> 00:21:04.480 I just told you. 00:21:05.560 --> 00:21:11.300 I mean, I understand the idea. I just don't understand why it works. I don't understand. 00:21:11.480 --> 00:21:12.160 It's magical math. 00:21:12.360 --> 00:21:17.880 Yes, exactly. Well, I feel that at some point I kind of understood it more than 00:21:17.880 --> 00:21:20.400 just magical math, but not right now. 00:21:20.760 --> 00:21:25.260 No, the magical math basically says that you've done some calculations before to 00:21:25.260 --> 00:21:30.380 make a filter from a block. And then you can check against the filter. You say, 00:21:30.520 --> 00:21:32.540 do these addresses belong to this block or not? 00:21:33.820 --> 00:21:35.680 Do you want to just leave it there? 00:21:36.240 --> 00:21:38.320 Yeah, because that's about as well as I can explain it. 00:21:38.400 --> 00:21:42.080 Okay, we'll leave it there. If you want to know more, I think we go a little bit 00:21:42.080 --> 00:21:44.080 more in depth in our actual Neutrino episode. 00:21:44.300 --> 00:21:45.240 We missed the topic. 00:21:46.330 --> 00:21:52.050 Well, I wasn't done, Sjors. I think you're going to bring up the RBF, the full 00:21:52.050 --> 00:21:52.510 RBF. 00:21:52.510 --> 00:21:55.680 No, no, no, no. Wait, there's 65-byte transactions. 00:21:55.970 --> 00:22:01.070 Oh, you're right. Oh, we missed a topic. That's a big one. You're so sharp today. 00:22:02.030 --> 00:22:07.410 Luckily, because I'm apparently not. Okay, so yes, there's something going on 00:22:07.410 --> 00:22:09.790 with the minimum size of transactions. 00:22:09.850 --> 00:22:11.790 Yeah, we added more freedom to the mempool. 00:22:13.660 --> 00:22:14.560 Is that so? 00:22:14.780 --> 00:22:15.060 Yes. 00:22:15.460 --> 00:22:16.100 Okay, explain. 00:22:16.640 --> 00:22:21.420 So remember there is consensus, which is what the rules for the blocks, and 00:22:21.420 --> 00:22:25.800 there's standardness, which is rules for the mempool. And generally the 00:22:25.800 --> 00:22:30.360 standardness rules are stricter than the consensus rules. In fact, that's always 00:22:30.360 --> 00:22:35.270 the case. In other words, there are some transactions that are perfectly fine in 00:22:35.270 --> 00:22:41.250 a block, but they are not fine in the mempool. And this usually has to do with 00:22:41.250 --> 00:22:46.220 preventing DoS, denial of service attacks, on your node. In this case, though, 00:22:46.220 --> 00:22:47.060 it's not really that. 00:22:48.480 --> 00:22:53.760 There is a minimum size. I believe it was 84 bytes. So any transaction that's 00:22:53.760 --> 00:22:58.120 less than 84 bytes would not be relayed by nodes. If it's in a block, it's fine. 00:22:58.400 --> 00:23:01.580 Is there a minimum size to be in blocks at all? 00:23:01.780 --> 00:23:05.900 I don't think so. There's probably a minimum practical size because you have to 00:23:05.900 --> 00:23:07.320 point to a previous transaction, etc. 00:23:08.700 --> 00:23:13.020 Yeah, there's an actual minimum size that a transaction can be, but there's no 00:23:13.020 --> 00:23:14.400 consensus rule for it. 00:23:14.640 --> 00:23:18.820 Yeah, I guess you'd say there's an inherent minimum size. It follows from what 00:23:18.820 --> 00:23:21.460 has to be in a transaction, but other than that, I don't think there's a number. 00:23:21.660 --> 00:23:26.880 Okay, but there is a minimum size for the mempool policy. 00:23:27.060 --> 00:23:30.900 Yeah, and I think it was something like 82 or 84, some number, and this number 00:23:30.900 --> 00:23:34.000 has been decreased. Now it's 65. 00:23:34.760 --> 00:23:35.620 Okay, why? 00:23:36.620 --> 00:23:41.820 Well, so why... I mean, there's some use for it. So I think the idea is it makes 00:23:41.820 --> 00:23:44.160 it a little bit easier to burn coins if you need to. 00:23:45.560 --> 00:23:46.420 To burn coins? 00:23:46.820 --> 00:23:50.620 Yeah, if you have some dust that you want to get rid of, you want to remove it 00:23:50.620 --> 00:23:51.460 from the UTXO set. 00:23:51.980 --> 00:23:52.340 Okay. 00:23:53.100 --> 00:23:55.460 I think it's easier to do that with smaller transactions. 00:23:56.970 --> 00:23:58.110 But the... 00:23:58.110 --> 00:24:00.750 Wait, what? Why would you want to do that? 00:24:01.070 --> 00:24:03.450 Because you want to clean up the UTXO set. 00:24:03.570 --> 00:24:06.730 But you literally just want to... throw away coins? 00:24:06.730 --> 00:24:10.270 Well you throw away coins that are not economical right? 00:24:10.980 --> 00:24:12.760 So why not just leave it alone? 00:24:12.760 --> 00:24:18.000 Because then it's sitting in people's memory and using up resources. Be 00:24:18.860 --> 00:24:20.560 a good citizen clean up your UTXOs 00:24:20.560 --> 00:24:22.820 I guess I guess okay yeah go on. 00:24:22.820 --> 00:24:27.320 There may also be uh things I mean I think this was proposed by instagibbs, 00:24:27.320 --> 00:24:32.850 [unclear] Sanders and he's working on ephemeral anchors which are ways to combine 00:24:32.850 --> 00:24:36.690 two transactions that are paying a zero fee and then one is bumping the other so 00:24:36.690 --> 00:24:40.270 maybe those transactions are actually smaller than and maybe that's why he needs 00:24:40.270 --> 00:24:44.570 it I haven't looked at the reasoning in any case it's possible so it's done um 00:24:44.570 --> 00:24:50.390 the original reason is kind of funny um the original limit was 00:24:50.390 --> 00:24:55.970 made this weird number like 82 or 84 because if they had made it 65 then the bad 00:24:55.970 --> 00:25:00.140 people would have understood why it was done and they might have been able to 00:25:00.140 --> 00:25:03.860 exploit something before the fix was released. So this is a case of you have a 00:25:03.860 --> 00:25:07.660 vulnerability. You know that if people make 64-byte transactions, they can cause 00:25:07.660 --> 00:25:12.220 problems. You don't want to give that away too, obviously. So you say, we're not 00:25:12.220 --> 00:25:15.780 going to make the limit 65. We're going to make it like 84 and then make up some 00:25:15.780 --> 00:25:19.180 excuse why 84 is a good number. Because nobody needed it. 00:25:19.480 --> 00:25:22.700 This is super confusing. Luckily, I know what you're talking about. 00:25:22.940 --> 00:25:24.620 All right. Well, maybe you can explain it. 00:25:24.720 --> 00:25:29.260 Yes. So you mentioned the original number, and you said that was 82. So that's 00:25:29.260 --> 00:25:34.440 the confusing part. No. The original number was 64. That was a minimum of 64. 00:25:34.740 --> 00:25:34.880 Yeah. 00:25:35.220 --> 00:25:36.480 And then it was increased? 00:25:36.660 --> 00:25:41.020 No, no. There was no minimum. But it had to be increased above 64. 00:25:41.490 --> 00:25:43.030 Oh, so it was not 64? 00:25:43.370 --> 00:25:44.210 No, I think it was… 00:25:44.450 --> 00:25:45.570