WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:15.820 --> 00:00:20.200 Live from Utrecht, this is Bitcoin Explained. Hey Sjors. 00:00:20.580 --> 00:00:20.960 Hello. 00:00:21.400 --> 00:00:26.980 First of all, I'd like to thank our sponsor Coinkite, the creator of 00:00:26.980 --> 00:00:29.080 the OPENDIME as well. 00:00:29.840 --> 00:00:30.520 That's right. 00:00:30.660 --> 00:00:33.380 Are we going to get sued if we only mention the OPENDIME, Sjors? 00:00:34.680 --> 00:00:35.080 No. 00:00:35.280 --> 00:00:39.720 Are we contractually obligated to mention the COLDCARD, or can we just riff off 00:00:39.720 --> 00:00:41.300 the OPENDIME this episode? 00:00:41.520 --> 00:00:45.640 If you want to riff on the OPENDIME for the great memories it brought us. 00:00:46.250 --> 00:00:49.010 The OPENDIME is pretty cool. I still have a few. 00:00:49.250 --> 00:00:49.990 What is an OPENDIME? 00:00:50.290 --> 00:00:55.050 It's like a USB stick, kind of small stick. You put it, you stick it in your 00:00:55.050 --> 00:00:59.330 computer, you put some Bitcoin on it, you hand it to someone, very cypherpunk 00:00:59.330 --> 00:01:03.950 technology, off chain, no one needs to know anything. And then that person can 00:01:03.950 --> 00:01:08.670 check that the Bitcoin are really on there and they can take the Bitcoin off only 00:01:08.670 --> 00:01:12.170 once. You have to sort of destroy the thing to get the coin off. 00:01:12.390 --> 00:01:15.270 Yeah, so you can see whether it was spent or not. You actually have to break it. 00:01:15.560 --> 00:01:21.190 Right. Very cool. So we're making another episode about another Bitcoin Core 00:01:21.190 --> 00:01:27.070 release. I feel like one every four episodes we make now is about a Bitcoin 00:01:27.070 --> 00:01:27.730 Core release. 00:01:28.420 --> 00:01:31.260 Yeah, those are a bit of our lazy episodes. 00:01:31.840 --> 00:01:36.020 Well, also, we don't make as much episodes. Or is Bitcoin Core making more 00:01:36.020 --> 00:01:37.120 Bitcoin Core releases? 00:01:37.360 --> 00:01:42.420 No, I can, however, tell you that Bitcoin Core version 27.0 will be the best 00:01:42.420 --> 00:01:44.240 Bitcoin node ever. 00:01:44.800 --> 00:01:47.600 Nice. So, Bitcoin Core 27. 00:01:49.610 --> 00:01:55.470 As we're recording this, it's in release phase. What is it? Release candidate 1? 00:01:55.730 --> 00:01:58.390 Yes, exactly. So people who would like to test it, they can. 00:01:58.890 --> 00:02:03.190 For any new listeners, Sjors, what does it mean that there's a new Bitcoin Core release? 00:02:04.120 --> 00:02:08.800 It kind of means nothing because in Bitcoin Core, there is a new release roughly 00:02:08.800 --> 00:02:13.560 every six months, regardless of what is finished. So whatever is finished goes 00:02:13.560 --> 00:02:18.140 into the release. What is not finished does not go into the release. It is not... 00:02:18.690 --> 00:02:20.510 Yeah, that's special, I guess. 00:02:20.710 --> 00:02:25.170 We should next time just ask Stein, our editor, to just cut this from the 00:02:25.170 --> 00:02:27.110 previous episode. You don't have to repeat. 00:02:27.290 --> 00:02:29.630 To see that I'm answering the question inconsistently. 00:02:30.170 --> 00:02:34.010 So yeah, every half year there's a big Core release. Whatever is ready by then 00:02:34.010 --> 00:02:36.810 goes into the release. Whatever is not, is not. 00:02:37.030 --> 00:02:40.610 Yeah, though one thing that I believe was observed is that the release started 00:02:40.610 --> 00:02:45.580 drifting a bit. So, you know, maybe it was in January on one year. And then the 00:02:45.580 --> 00:02:49.700 next year it was in February, and the next year it was in March. So this release 00:02:49.700 --> 00:02:52.720 is a relatively short one to try and reset the schedule a bit. 00:02:53.470 --> 00:02:56.430 I see. Okay, so when was the previous one? Do you know this? 00:02:56.790 --> 00:03:00.970 I think it was in November, maybe. It should be every six months. 00:03:01.210 --> 00:03:02.510 That's six months ago. 00:03:04.240 --> 00:03:08.300 Okay, so Release Candidate 1, what does that mean? Also for new listeners? 00:03:08.760 --> 00:03:13.000 Yeah, so what happens is there's a couple of phases to the release. The first 00:03:13.000 --> 00:03:14.360 phase is the so-called... 00:03:16.470 --> 00:03:21.610 sort of the bug fix time. So there's a master branch where all the changes go 00:03:21.610 --> 00:03:25.270 that Bitcoin Core makes. And everything in the master branch should be bug free. 00:03:25.990 --> 00:03:30.890 But sometimes it's not. And the idea is that a few weeks before the branch off 00:03:30.890 --> 00:03:35.720 point, which I'll explain in a bit, people stop merging or maintainers stop 00:03:35.720 --> 00:03:40.220 merging things that are features and try to merge only somewhat more conservative 00:03:40.220 --> 00:03:45.180 bug fixes, typo changes, that sort of stuff to make sure that there are, you 00:03:45.180 --> 00:03:48.840 know, to reduce the chance of having any bugs on that master branch in the first place. 00:03:51.120 --> 00:03:56.380 And then what happens is this branch off, which is where a separate Git branch is 00:03:56.380 --> 00:04:01.600 created where all the changes, which only has bug fixes. 00:04:02.560 --> 00:04:05.940 So to understand what that means is there is still the master branch, and people 00:04:05.940 --> 00:04:08.700 are still developing on that, but anything that goes onto the master branch will 00:04:08.700 --> 00:04:09.780 not go into the release. 00:04:10.700 --> 00:04:14.900 Wait, but I was asking about the release process, basically. We're in release 00:04:14.900 --> 00:04:16.120 candidate one. 00:04:16.240 --> 00:04:16.660 We'll get there. 00:04:17.120 --> 00:04:17.980 Oh, okay. 00:04:18.120 --> 00:04:19.380 I'm just going a little bit back there. 00:04:19.460 --> 00:04:19.860 Okay, go. 00:04:20.020 --> 00:04:23.920 So, yeah, so the master branch, people can continue to have fun there. That's 00:04:23.920 --> 00:04:26.440 going to be for the next release. Meanwhile, there is this separate branch for 00:04:26.440 --> 00:04:32.320 the release, which has only maybe very minor bug fixes. And then 00:04:32.320 --> 00:04:37.960 to that branch are added a few things to change the version number. And then 00:04:37.960 --> 00:04:43.180 that is turned into a release candidate. And that release candidate is 00:04:43.240 --> 00:04:48.160 first, let's say people 00:04:48.160 --> 00:04:53.360 test it a little bit who are developers. And then once that's done, there is a 00:04:53.360 --> 00:04:56.460 binary release that people can download and test that. 00:04:57.710 --> 00:05:02.010 So what do we have now? Where are we? Do we have a binary release? 00:05:02.170 --> 00:05:04.730 Yes, there's a binary release for release candidate. 00:05:04.950 --> 00:05:07.670 Okay, so how many release candidates are there going to be? 00:05:07.870 --> 00:05:11.230 Well, so what happens then is for about two weeks, people can test it. And then 00:05:11.230 --> 00:05:16.310 if they don't find any bugs, then we essentially make the same binary and call it 00:05:16.310 --> 00:05:17.190 the final version. 00:05:17.370 --> 00:05:17.550 Right. 00:05:17.630 --> 00:05:21.290 It's not technically the same binary. We talked about hashes before. The version 00:05:21.290 --> 00:05:25.290 number is in the binary. So a different version number means a different hash. 00:05:25.820 --> 00:05:28.080 But other than the version number, it should be identical. 00:05:28.400 --> 00:05:31.940 Okay, so the current release candidate could potentially be the next Bitcoin Core 00:05:31.940 --> 00:05:35.600 27, but maybe bugs are found, then the bugs are fixed, and then there will be 00:05:35.600 --> 00:05:38.640 another release candidate, and then that could be the next Bitcoin Core 27. 00:05:38.960 --> 00:05:43.180 Yeah, and so whenever a bug is fixed, it is first fixed on the master branch, so 00:05:43.180 --> 00:05:48.640 it also applies to future releases, and then it's backported, as it's called, to 00:05:48.640 --> 00:05:51.990 the release branch. And that means that the same fix that was applied to the 00:05:51.990 --> 00:05:56.330 master branch is then also applied to the release branch. That's extra work. So 00:05:56.330 --> 00:06:01.890 ideally that should not happen too often. Hence the need to not have bugs in the 00:06:01.890 --> 00:06:02.410 master branch. 00:06:03.090 --> 00:06:06.890 Right. Anyways, as soon as there's no bugs in the release candidate, we have a 00:06:06.890 --> 00:06:09.870 new Bitcoin Core release, which in this case will be Bitcoin Core 27. 00:06:10.450 --> 00:06:10.890 Exactly. 00:06:11.290 --> 00:06:16.420 And we are going to discuss some of the... highlights of this new Bitcoin Core 00:06:16.420 --> 00:06:20.120 release. Why should people download it? Why should people care? Why, dear 00:06:20.120 --> 00:06:25.100 listener, do you want to use Bitcoin Core 27? Sjors will explain it all today. 00:06:25.620 --> 00:06:29.880 Exactly. Well, first of all, there's something that's not in Bitcoin Core version 00:06:29.880 --> 00:06:30.420 27. 00:06:31.470 --> 00:06:37.150 Yeah, something was jacked out. libbitcoinconsensus, which has nothing to do with 00:06:37.150 --> 00:06:37.790 libbitcoin. 00:06:38.170 --> 00:06:42.840 Yeah, although I think I should say it's not removed, it's deprecated, which 00:06:42.840 --> 00:06:46.380 means that this is your last warning. It's going to go away in 28. 00:06:48.390 --> 00:06:52.550 Okay. Wait, so it's still... Okay, just explain what it is. 00:06:52.690 --> 00:06:57.690 Yeah, so deprecation is always a warning, like this thing is going to go away the 00:06:57.690 --> 00:07:01.570 next time. So sometimes if you use a feature that's deprecated, it will tell you, 00:07:01.630 --> 00:07:05.030 hey, this feature is deprecated. Sometimes you even have to actively set a 00:07:05.030 --> 00:07:09.330 configuration to use a deprecated feature. So the first time you try to use it, 00:07:09.390 --> 00:07:14.080 it says no. And then you make a change to the configuration, says, okay, I'll do 00:07:14.080 --> 00:07:17.840 it, but it's going to go away next time. So, you know, be careful there. 00:07:17.960 --> 00:07:18.600 You've been warned. 00:07:18.840 --> 00:07:20.680 Yeah. So this thing goes away. 00:07:20.840 --> 00:07:23.720 So what is this thing? And why is it going away? 00:07:23.940 --> 00:07:29.840 So in the early days, there was a demand to have or a 00:07:29.840 --> 00:07:35.120 desire to have the core functionality of Bitcoin Core. So the part that checks 00:07:35.120 --> 00:07:39.970 the consensus rules to somehow split that off from the rest. Other people can 00:07:39.970 --> 00:07:44.510 make their own node software or do other things and don't care about all the 00:07:44.510 --> 00:07:47.890 whistles and bells that are in Bitcoin Core. So they don't want a GUI, they don't 00:07:47.890 --> 00:07:48.690 want... 00:07:48.690 --> 00:07:53.530 So in other words, that would basically be the rules that define which blocks are 00:07:53.530 --> 00:07:57.250 valid, right? That's really the core consensus rules? 00:07:57.470 --> 00:08:02.190 Well, yeah, the question is, what is exactly the core consensus rules? That's an 00:08:02.190 --> 00:08:07.980 open question still. But at the time, this library, this libbitcoinconsensus, was 00:08:07.980 --> 00:08:11.960 limited to, I believe, things that can check signatures. It wasn't even fully 00:08:11.960 --> 00:08:15.940 checking a block. It could just verify individual transactions and signatures. 00:08:16.300 --> 00:08:16.780 Okay. 00:08:17.020 --> 00:08:22.370 So it was a very limited subset of what we consider the validity. 00:08:23.010 --> 00:08:24.890 Okay, but that's because it wasn't finished yet? 00:08:25.810 --> 00:08:28.230 Yeah, it was a work in progress. It was the first attempt. 00:08:29.490 --> 00:08:33.630 But it wasn't finished, and it's quite difficult to maintain. Wow. 00:08:33.970 --> 00:08:37.650 So do you know why it wasn't finished? What's hard to maintain about it? 00:08:39.130 --> 00:08:43.940 Not really. It was just a pain in the ass. And now we have the kernel project, 00:08:43.940 --> 00:08:46.860 which tries it again and uses a different approach. 00:08:47.160 --> 00:08:51.280 Right. I mean, from what I understand or what I remember, at least years ago when 00:08:51.280 --> 00:08:56.340 I heard about this, the Bitcoin Core... at least as it was then and probably 00:08:56.340 --> 00:09:00.760 still, or at least as Satoshi released, it was kind of spaghetti code. Spaghetti 00:09:00.760 --> 00:09:04.000 code where everything sort of refers to everything else and some of it was 00:09:04.000 --> 00:09:08.940 consensus and some of it was not. So it was very hard to sort of derive from that 00:09:08.940 --> 00:09:14.100 mess what actually was consensus. And that sort of was the big challenge to 00:09:14.100 --> 00:09:19.860 getting this done. So it sounds like this project was started. I 00:09:19.860 --> 00:09:24.410 think especially Jorge Timon was working on this. And it sounds like he kind of 00:09:24.410 --> 00:09:28.310 went away and probably people sort of stopped caring about this project. And now 00:09:28.310 --> 00:09:33.170 Bitcoin Core Dev said, let's just get rid of this thing. Let's start over. Let's 00:09:33.170 --> 00:09:33.630 start fresh. 00:09:34.130 --> 00:09:36.770 Yeah, I think so, and I think it was also getting in the way of some other 00:09:36.770 --> 00:09:38.650 refactoring cleanup projects. 00:09:38.910 --> 00:09:42.610 Right, and this Bitcoin kernel you just mentioned, have we talked about this on the podcast? 00:09:43.450 --> 00:09:48.130 We've mentioned it a couple of times. The TLDR is it's an attempt, again, to take 00:09:48.130 --> 00:09:52.370 the essence of Bitcoin Core and make it available for other software. Now, 00:09:52.450 --> 00:09:56.770 there's still an open question of what should and should not be part of the 00:09:56.770 --> 00:10:02.230 kernel. For example, does the mempool belong to the kernel or just blocks? 00:10:03.730 --> 00:10:07.850 And we've seen that even network rules impact consensus. We've seen that very 00:10:07.850 --> 00:10:12.510 clearly with an episode we did about a btcd bug. 00:10:13.690 --> 00:10:19.330 Yeah, I think it was a btcd bug for using with LND, where a block was sent and it 00:10:19.330 --> 00:10:22.370 was rejected. But it wasn't rejected based on the consensus rules. It was 00:10:22.370 --> 00:10:27.010 rejected based on a network rule, saying that the block had too many, I don't 00:10:27.010 --> 00:10:27.510 know what it was. 00:10:27.890 --> 00:10:28.090 Yeah. 00:10:28.290 --> 00:10:29.170 We have a little episode about it. 00:10:29.530 --> 00:10:34.390 Okay. Anyways, libbitcoinconsensus is deprecated. 00:10:34.630 --> 00:10:38.050 Yes. So as a user, you will not notice this at all. 00:10:39.260 --> 00:10:44.460 Right. Okay. Let's move to something that you might use as a user, might notice 00:10:44.460 --> 00:10:44.980 as a user. 00:10:47.080 --> 00:10:50.420 Actually, I don't think the next one is going to be noticeable by a user either. 00:10:50.860 --> 00:10:51.820 No, it might be. It might be. 00:10:51.960 --> 00:10:52.160 Okay. 00:10:53.920 --> 00:10:55.300 This is about the mempool. 00:10:55.920 --> 00:10:59.260 Yeah, to be precise, it's about saving the mempool. 00:10:59.680 --> 00:11:01.620 About saving the mempools. 00:11:02.310 --> 00:11:03.950 Well, your mempool, yeah. 00:11:04.730 --> 00:11:08.110 Saving the mempool. Saving my mempool. How are we going to save my mempool? 00:11:08.490 --> 00:11:13.270 Yeah, so Bitcoin Core, when it's running, it receives new transactions. It holds 00:11:13.270 --> 00:11:17.930 onto those, usually in memory. And then at some point, you shut Bitcoin Core down. 00:11:17.930 --> 00:11:19.990 This is before they're included in a block. 00:11:20.500 --> 00:11:24.700 Yes, exactly. And then either if a block arrives to go out of the mempool because 00:11:24.700 --> 00:11:29.780 now they're in a block, or if you shut down Bitcoin Core but the transaction is 00:11:29.780 --> 00:11:33.640 still not in a block, it's going to remember it by saving it to disk. And then 00:11:33.640 --> 00:11:36.880 next time you start Bitcoin Core, it loads it from disk. Otherwise, you'd have to 00:11:36.880 --> 00:11:39.580 wait for somebody else to announce it again to you, which is not ideal. 00:11:39.680 --> 00:11:41.120 Or it's in a block, right, by then. 00:11:41.560 --> 00:11:42.020 Yeah. 00:11:42.620 --> 00:11:45.780 I mean, there's no real... What's actually the point now that I ask this 00:11:45.780 --> 00:11:50.720 question? Like, why should I care as a regular user that my mempool is cleared? 00:11:51.140 --> 00:11:55.080 Well, we did an episode about why the mempool is useful in general. 00:11:56.360 --> 00:12:00.920 You know, it helps with things like block relay. It makes it quicker for you to 00:12:00.920 --> 00:12:06.090 verify a new block because you already verified those transactions before. So 00:12:06.090 --> 00:12:09.850 then when you restart Bitcoin Core, it helps you to verify all those new blocks 00:12:09.850 --> 00:12:12.590 that you're going to catch up with with that mempool that you still had. 00:12:12.950 --> 00:12:18.490 Right, okay. So yeah, I have a Bitcoin Core node and the mempool, when I shut 00:12:18.490 --> 00:12:22.910 down my computer, my entire mempool is just saved on disk and then I start the 00:12:22.910 --> 00:12:26.690 computer again and Bitcoin Core starts up and it remembers what was in the mempool. 00:12:26.890 --> 00:12:27.230 Exactly. 00:12:27.450 --> 00:12:29.470 Okay, so what's the problem? 00:12:29.730 --> 00:12:31.330 The problem is that... 00:12:32.560 --> 00:12:36.700 There, you might have a virus scanner, and that virus scanner is looking for 00:12:36.700 --> 00:12:42.340 suspicious files. And if some joker creates a 00:12:42.340 --> 00:12:46.600 transaction and then puts one of this OP_RETURN spam inscriptions, whatever it 00:12:46.600 --> 00:12:50.520 is, in there, they could put something in that looks like a virus. 00:12:51.710 --> 00:12:53.690 Whether it is a virus or not. Well, 00:12:54.150 --> 00:12:57.850 that's a philosophical question. Is a photo of a virus a virus? I don't think so 00:12:57.850 --> 00:13:00.250 because it's not going to replicate or do any harm. 00:13:00.450 --> 00:13:00.650 Okay. 00:13:00.910 --> 00:13:03.510 Right? So it's more like a picture of a virus, I guess. 00:13:03.670 --> 00:13:03.810 Okay. 00:13:03.810 --> 00:13:08.350 It might be the exact same code. It's not that your node is suddenly going to run 00:13:08.350 --> 00:13:13.610 the virus and destroy itself. But the virus scanner doesn't understand that. So 00:13:13.610 --> 00:13:17.050 it sees something that looks like a virus and says, I'm going to put this in 00:13:17.050 --> 00:13:21.980 quarantine now, and then puts your whole mempool in quarantine. And now when you 00:13:21.980 --> 00:13:25.720 start the node again, it's not going to break. It's just going to say, oh, I 00:13:25.720 --> 00:13:27.760 guess you don't have a mempool yet. Let me make a new one. 00:13:29.230 --> 00:13:29.490 Uh-huh. 00:13:30.170 --> 00:13:33.250 That's not ideal because we just explained why we saved this thing in the first 00:13:33.250 --> 00:13:34.490 place. 00:13:34.790 --> 00:13:38.770 Can't say I feel very stressed about this problem, but sure, go on. 00:13:38.970 --> 00:13:43.310 No, this is why this problem has not been fixed for the past 10 years. We do the 00:13:43.310 --> 00:13:48.010 same thing for blocks that are stored on disk. Well, what we'll do, we'll explain 00:13:48.010 --> 00:13:51.590 in a bit, but we have the same problem for blocks. I think that actually did 00:13:51.590 --> 00:13:56.490 happen in like 10 years ago. Some joker put something in a block that looked like a virus. 00:13:56.650 --> 00:13:57.830 It's better to solve the problem. 00:13:58.030 --> 00:14:03.210 Yeah, because if your blocks are killed by the virus scanner, then your node 00:14:03.210 --> 00:14:03.950 doesn't work anymore. 00:14:04.150 --> 00:14:04.550 Right. 00:14:04.810 --> 00:14:05.810 So that's more important. 00:14:05.930 --> 00:14:06.170 Yes. 00:14:07.440 --> 00:14:13.440 And so transactions, yeah, okay, so what's the solution here? What are we trying to do? 00:14:14.020 --> 00:14:19.630 The solution here... is to basically fool the virus scanner 00:14:19.630 --> 00:14:25.450 by encrypting the file. Now, encrypting sounds very fancy. It's not the 00:14:25.450 --> 00:14:30.010 strongest encryption ever, but it is using XOR, basically. 00:14:31.230 --> 00:14:31.970 And what's XOR? 00:14:33.530 --> 00:14:38.610 XOR, well, I guess the easiest is to explain it. It's like a one-time pad. So 00:14:38.610 --> 00:14:43.940 this is one of the oldest forms of encryptions that exist. You take a text that 00:14:43.940 --> 00:14:48.860 you want to encrypt, like the word hello, and then you add to it a set of random 00:14:48.860 --> 00:14:53.920 letters. That's the easiest way to see it that you've agreed to before. So you 00:14:53.920 --> 00:14:58.700 and I want to communicate. We exchange a long piece of paper with lots of letters 00:14:58.700 --> 00:15:04.340 on it. And then we say whenever we write a letter to each other, we both 00:15:04.340 --> 00:15:08.460 start with that piece of paper and we add the letter on that piece of paper to 00:15:08.460 --> 00:15:13.890 every letter that we write. Or I add the letter and you subtract it. And that 00:15:13.890 --> 00:15:14.430 way... 00:15:14.430 --> 00:15:18.790 Wait, so this sounds like the Caesar cipher. Do you know what this is? 00:15:19.210 --> 00:15:21.050 No, it's much more secure. 00:15:21.770 --> 00:15:23.250 Oh, it is more secure than that? 00:15:23.350 --> 00:15:28.110 Yeah, I think the Caesar cipher was... Actually, I don't know. It might be similar. 00:15:28.350 --> 00:15:33.010 The Caesar cipher, which I describe... in the Genesis book. 00:15:33.190 --> 00:15:34.350 Oh, yes, you wrote a book. 00:15:35.490 --> 00:15:41.250 It's basically you take the word hello and then you do like plus five and then 00:15:41.250 --> 00:15:47.130 for each letter you replace the letter in hello for like the fifth next letter 00:15:47.130 --> 00:15:47.710 in the alphabet. 00:15:48.150 --> 00:15:52.130 Yeah, but if you do it just plus five for every letter, that's a bit easy to crack. 00:15:52.290 --> 00:15:54.250 I mean, it is, but that's the Caesar cipher. 00:15:54.310 --> 00:15:59.850 So this cipher means every... Every character gets, you add a different letter or 00:15:59.850 --> 00:16:01.250 a different number to every character. 00:16:02.600 --> 00:16:06.820 And that number is random every time. So you have a page with completely random 00:16:06.820 --> 00:16:10.780 numbers that you created with dice throwing, whatever it is. Numbers 0 to 26, 00:16:11.160 --> 00:16:12.440 right? Or 0 to 25. 00:16:14.590 --> 00:16:19.170 And when I'm writing you the message, I'm adding a different number to every 00:16:19.170 --> 00:16:22.990 letter of my message, and you have to keep track of where I am, and then you can 00:16:22.990 --> 00:16:27.870 subtract the same number. And then you burn the piece of paper that we used as a 00:16:27.870 --> 00:16:33.150 cipher. So that means anybody who intercepts the communication midway can no 00:16:33.150 --> 00:16:33.930 longer decipher it. 00:16:35.330 --> 00:16:37.570 Anyways, so the mempool is encrypted. 00:16:38.070 --> 00:16:42.070 Using roughly that technique, except a very insecure version of it, because the 00:16:42.070 --> 00:16:46.490 entire thing is only like eight characters long, and it just repeats the same 00:16:46.490 --> 00:16:49.770 eight characters, which is insecure. And also at the start of the file, the 00:16:49.770 --> 00:16:54.230 cipher is actually revealed, so it is totally insecure, because it's not the goal 00:16:54.230 --> 00:16:56.430 to be secure, it's the goal to fool the virus scanner. 00:16:57.750 --> 00:17:00.880 Yep. Okay, that's it. Mempool upgrade. 00:17:01.180 --> 00:17:05.940 Yeah, and so the little thing there is that means you can't downgrade. Because 00:17:05.940 --> 00:17:09.060 older versions of the node, if you wanted to go back to an old version, won't 00:17:09.060 --> 00:17:15.020 understand the mempool file. But they'll just start a new one. So it's not a big deal. 00:17:15.820 --> 00:17:17.680 Okay. Next one. 00:17:20.950 --> 00:17:26.730 BIP 324. We made an episode on that. That's network encryption. And that's 00:17:26.730 --> 00:17:28.070 now on by default. 00:17:28.490 --> 00:17:28.970 Yes. 00:17:29.210 --> 00:17:32.910 So it was already an option in the previous Bitcoin Core release. 00:17:32.990 --> 00:17:33.150 Yep. 00:17:33.630 --> 00:17:37.210 Maybe even the one before that? No, probably the previous one, I think, right? 00:17:37.350 --> 00:17:40.670 I think the previous one or the one before it, it was made default. 00:17:41.030 --> 00:17:41.790 No, it was. 00:17:41.950 --> 00:17:43.650 It was available. You could turn it on. 00:17:43.710 --> 00:17:43.890 Yeah. 00:17:44.130 --> 00:17:45.310 And now it's on by default. 00:17:45.490 --> 00:17:48.810 Right. Okay. Quick reminder what it was again. 00:17:48.990 --> 00:17:49.850 Episode 77. 00:17:51.340 --> 00:17:52.060 No, sure. 00:17:53.040 --> 00:17:56.540 Stein can just paste it. No, that's fine. 00:17:57.920 --> 00:18:03.880 The idea is that you and I have a connection, and instead of sending everything 00:18:03.880 --> 00:18:06.520 in plain text, we encrypt everything. 00:18:06.860 --> 00:18:10.580 Yep. Okay, I mean, I guess, actually, yeah, that's good enough. If you do want to 00:18:10.580 --> 00:18:11.720 know more, we made an episode on it. 00:18:11.720 --> 00:18:14.840 Which starts with the Diffie-Hellman key exchange, which you have described in 00:18:14.840 --> 00:18:15.260 your book. 00:18:15.890 --> 00:18:17.710 Oh, thanks. You're plugging it as well. 00:18:17.810 --> 00:18:22.870 And then you use a stream cipher, which is essentially a one-time pad where this 00:18:22.870 --> 00:18:27.270 piece of paper that we talked about, we know that given the key exchange we did, 00:18:27.410 --> 00:18:31.490 we know what that page has to look like. So we don't have to give each other a 00:18:31.490 --> 00:18:36.430 piece of paper with the cipher on it. We both construct the same cipher, but it's 00:18:36.430 --> 00:18:42.130 the same cryptographic idea. So that's pretty cool. It's on by default. 00:18:42.130 --> 00:18:46.500 This does not mean that all your connections are now encrypted by default. The 00:18:46.500 --> 00:18:52.220 devil is in the details here. When you connect to a new node, you will try 00:18:52.220 --> 00:18:57.200 this encryption only if you think the other side supports it. 00:18:58.050 --> 00:19:02.230 And we talked in a very, very early episode about DNS seeds, probably episode two. 00:19:03.180 --> 00:19:03.880 Oh, wow. 00:19:04.200 --> 00:19:09.480 Where, you know, the way nodes bootstrap is they get a list of other nodes and 00:19:09.480 --> 00:19:12.820 then they call those other nodes and say, hey, do you know about other nodes? And 00:19:12.820 --> 00:19:17.320 you keep a list of which nodes exist in the network. But you don't just keep 00:19:17.320 --> 00:19:21.260 track of which nodes exist and their IP addresses. You also check which features 00:19:21.260 --> 00:19:25.400 they support. And one of those features can be that they support this encrypted 00:19:25.400 --> 00:19:31.000 communication. So only if through the gossip circuit you heard 00:19:31.000 --> 00:19:35.280 that this node supports encryption, then you're going to try it. Otherwise, 00:19:35.300 --> 00:19:40.360 you're not. And so this will probably be a future change. If we know that this 00:19:40.360 --> 00:19:46.140 works, then we might just try an encrypted connection all the time and fall 00:19:46.140 --> 00:19:50.690 back to unencrypted if it doesn't work. So now this is, even though it's on by 00:19:50.690 --> 00:19:51.950 default, it's still a bit conservative. 00:19:53.630 --> 00:19:58.390 Right. Okay, so so far we talked about something that was removed, 00:19:58.410 --> 00:20:01.070 something that's a very niche problem. 00:20:01.940 --> 00:20:03.420 Not niche if you use Windows, 00:20:04.780 --> 00:20:06.100 but... 00:20:06.710 --> 00:20:10.710 Well, no, I think you're... We're not there yet. 00:20:10.850 --> 00:20:11.150 Okay. 00:20:11.840 --> 00:20:17.020 I said so far we've talked about something that was removed, something that 00:20:17.020 --> 00:20:20.680 solves a weird virus thing. 00:20:20.980 --> 00:20:25.240 Yeah, but that may not be a weird problem. If somebody does this, then it's going 00:20:25.240 --> 00:20:28.400 to affect everybody who runs a virus scanner, like not just a few people. 00:20:28.580 --> 00:20:33.420 I'm not impressed, Sjors. Where are my soft forks? Where are my... 00:20:34.710 --> 00:20:37.370 Does this make number go up? I don't think so. 00:20:37.490 --> 00:20:38.830 This is finally fixed Lightning. 00:20:39.430 --> 00:20:44.630 Yes, please. Okay, moving on to the next one. Network adjusted time removed. 00:20:44.830 --> 00:20:46.190 Speaking of unimportant problems. 00:20:47.480 --> 00:20:53.310 Yeah, so there is this rule that says if you see a new block, that 00:20:53.310 --> 00:20:57.610 it cannot be from the future. Well, it cannot be for more than two hours in the 00:20:57.610 --> 00:21:01.610 future. There's a little grace period there. Question is, what is two hours in 00:21:01.610 --> 00:21:05.460 the future? What if your clock is wrong? You might be wrong about that. 00:21:05.520 --> 00:21:10.060 Wait, let me repeat that for those that don't know and didn't quite follow. Yeah, 00:21:10.240 --> 00:21:15.280 you find a new block or someone sends you a new block. The block has a time in 00:21:15.280 --> 00:21:20.060 it. And then one of the things you do to check if the block is valid is to check 00:21:20.060 --> 00:21:24.100 that it wasn't mined in the future or in the past, I guess, right? 00:21:24.420 --> 00:21:26.920 No, the past is fine because you might be catching up on all blocks. 00:21:27.100 --> 00:21:31.500 Okay, yeah. It's not mined in the future. And the future means two hours or more 00:21:31.500 --> 00:21:32.180 into the future. 00:21:32.460 --> 00:21:35.520 Yeah. Now, there are limitations to the past, by the way, but that is relative to 00:21:35.520 --> 00:21:36.420 earlier blocks, right? 00:21:36.500 --> 00:21:36.620 Right. 00:21:37.020 --> 00:21:38.240 Blocks can't go back in time. 00:21:38.480 --> 00:21:38.640 Right. 00:21:38.880 --> 00:21:42.760 But, yeah, you cannot accept the block. 00:21:42.860 --> 00:21:44.600 Right, now we're talking about blocks in the future. 00:21:44.920 --> 00:21:45.240 Yeah. 00:21:45.340 --> 00:21:49.620 They can't be mined in the future, which is two hours in the future, and now what 00:21:49.620 --> 00:21:54.080 you said is how do you define what is the future? Well, usually you use a clock, 00:21:54.220 --> 00:21:55.560 and I guess that's what you're getting at. 00:21:55.620 --> 00:21:59.120 Yeah, and so I think it was Satoshi or maybe one of the earlier contributors who 00:21:59.120 --> 00:22:03.060 thought, well, what if your clock is wrong? You might be rejecting blocks even 00:22:03.060 --> 00:22:07.820 though they're valid because your clock is wrong, not the miner's clock. And the 00:22:07.820 --> 00:22:12.450 solution to that was to when you connect to other peers, you ask them, hey, what 00:22:12.450 --> 00:22:16.610 time is it? What time is it? What time is it? You know, not that long ago, that's 00:22:16.610 --> 00:22:18.170 a question you would ask people on the street. 00:22:18.290 --> 00:22:18.470 Yeah. 00:22:19.650 --> 00:22:20.210 It's amazing. 00:22:20.410 --> 00:22:21.030 Do you have the time? 00:22:21.210 --> 00:22:27.170 Yeah, exactly. Nowadays, well, we stopped doing that as humans, and 00:22:27.170 --> 00:22:31.510 Bitcoin Core stops doing that now too. Well, not entirely, but it doesn't do 00:22:31.510 --> 00:22:35.790 anything with it anymore. That's the change. Because the problem is, what if your 00:22:35.790 --> 00:22:41.660 peers are lying to you about the clock? That's not ideal. And also, you know, 00:22:42.020 --> 00:22:47.960 I think most computers nowadays get their clocks set by a network, you know, 00:22:48.360 --> 00:22:51.400 get the time from the network, from their internet provider or from some other 00:22:51.400 --> 00:22:55.940 source. And so my thinking is that they're generally either very accurate within 00:22:55.940 --> 00:22:59.630 the second or they are completely wrong because... 00:22:59.630 --> 00:23:00.510 Yeah, it's 1900. 00:23:01.190 --> 00:23:07.090 Yeah, I've had one of these cheap computers where the little battery is dead. So 00:23:07.090 --> 00:23:12.910 when you turn it on, the clock is back at the second zero, which is January 1st, 00:23:12.970 --> 00:23:13.410 1970. 00:23:14.550 --> 00:23:15.010 Is that it? 00:23:15.170 --> 00:23:17.530 That's typically the year zero for a computer. Right. 00:23:19.130 --> 00:23:19.390 Okay. 00:23:19.590 --> 00:23:24.450 So yeah, so now I think it will still warn you. Like, hey, this block seems to be 00:23:24.450 --> 00:23:29.970 [unclear]… Yeah. No, I think it'll warn you saying, hey, your peers think that 00:23:29.970 --> 00:23:34.730 time is different than I think it is, but that's it. It's just going to work. 00:23:34.830 --> 00:23:35.910 It's going to use its own clock. 00:23:36.390 --> 00:23:40.930 Do you think that in the future when religion is just displaced, we'll actually 00:23:40.930 --> 00:23:46.050 use 1970 as the year zero? You think future humans will think that way? Sure. 00:23:47.400 --> 00:23:51.260 Do you think that when we invent something better than a QWERTY keyboard, we'll 00:23:51.260 --> 00:23:51.920 actually use it? 00:23:53.160 --> 00:23:56.300 I'm still holding my breath. I'm not going to hold my breath for that one. 00:23:56.500 --> 00:23:58.100 I don't think we're going to change this. 00:23:58.480 --> 00:23:58.700 Okay. 00:24:01.730 --> 00:24:04.130 Because the QWERTY keyboard is not going to change? 00:24:04.310 --> 00:24:08.690 If we don't change the QWERTY keyboard with obvious productivity benefits, why 00:24:08.690 --> 00:24:13.110 would we replace the calendar system, which doesn't matter? 00:24:14.320 --> 00:24:14.800 Never? 00:24:16.520 --> 00:24:19.040 I'm sure at some point people will be like, oh, it's the year 00:24:19.040 --> 00:24:24.880 370,225,695. Yeah, that 00:24:24.880 --> 00:24:28.700 gets a little tedious. But maybe they'll just not count the thousands or 00:24:28.700 --> 00:24:29.320 something like that. 00:24:30.120 --> 00:24:34.560 Or we change it to 1971. That's what Bitcoiners will agree with. 00:24:36.020 --> 00:24:37.560 Should we move on to the next point? 00:24:37.740 --> 00:24:39.780 A rounding error in 300 million years. 00:24:41.620 --> 00:24:42.360 Next point. 00:24:46.390 --> 00:24:47.990