WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.400 --> 00:00:22.540 Live from Utrecht, this is Bitcoin 00:00:22.540 --> 00:00:23.840 Explained. 00:00:24.280 --> 00:00:24.900 Hello, Sjors. 00:00:25.460 --> 00:00:25.700 What's up? 00:00:25.840 --> 00:00:26.560 Welcome back. 00:00:26.920 --> 00:00:27.300 Thank you. 00:00:27.960 --> 00:00:30.800 You've been back for... Do you even live in this country still? 00:00:30.980 --> 00:00:32.280 I certainly do, yes. 00:00:32.360 --> 00:00:33.620 You were gone for like two months? 00:00:33.800 --> 00:00:35.080 No, one month. 00:00:36.440 --> 00:00:39.740 One month, a couple of conferences. Where did you go? 00:00:39.880 --> 00:00:44.460 Too many conferences, in fact. Bitcoin Indonesia, Nostrasia in Tokyo. 00:00:44.940 --> 00:00:48.200 Well, but the thing is, before that, you were in the States for a while, you were 00:00:48.200 --> 00:00:48.640 in Portugal. 00:00:49.180 --> 00:00:51.080 I was, but I was home for a few weeks in between. 00:00:51.620 --> 00:00:54.420 All right. Well, you were gone for so long that there's a new Bitcoin Core 00:00:54.420 --> 00:00:54.840 release. 00:00:55.440 --> 00:00:56.060 That's right. 00:00:56.300 --> 00:01:00.740 Bitcoin Core 26, but... Before we get into, so that's what this episode is going 00:01:00.740 --> 00:01:03.600 to be about. Sjors, we're going to discuss Bitcoin Core 26. 00:01:03.900 --> 00:01:04.160 Cool. 00:01:04.420 --> 00:01:08.680 But there's been some recent developments that you suggest that we briefly touch 00:01:08.680 --> 00:01:09.820 on before we get there. 00:01:10.120 --> 00:01:15.880 Yeah, I think so. So remember, dear listeners, if you listen to episode 37 00:01:15.880 --> 00:01:21.000 back in 2021, we talked about MARA Pool, which at the time was making blocks that 00:01:21.000 --> 00:01:26.700 they said were OFAC compliant. As far as we know, they did not actually do any 00:01:26.700 --> 00:01:32.420 filtering. But this triggered a developer, which we will call 00:01:32.420 --> 00:01:38.260 0xB10C, to 00:01:38.840 --> 00:01:44.800 write a tool that monitors the blockchain for said censorship, just in case 00:01:44.800 --> 00:01:45.660 that would ever happen. 00:01:45.900 --> 00:01:51.860 Yeah, so just to reiterate what this all means. There is an OFAC list, and this 00:01:51.860 --> 00:01:57.420 means there are entities on there that you're not allowed to transact with, and 00:01:57.420 --> 00:02:02.200 that's the US government sanctioned list. Is that the right way to think about it? 00:02:02.360 --> 00:02:02.760 Yes, correct. 00:02:03.020 --> 00:02:06.840 So these would include... people that the US government does not like, 00:02:07.060 --> 00:02:07.780 essentially. 00:02:08.200 --> 00:02:11.000 Yes, these are only people that the US government does not like. 00:02:11.340 --> 00:02:14.460 Right, and there are Bitcoin addresses on this list? 00:02:14.520 --> 00:02:17.580 Yeah, so I think the general idea is that they say, hey, this guy and this guy, 00:02:17.680 --> 00:02:20.700 you should not do business with them, and this is how you recognize them, and 00:02:20.700 --> 00:02:25.040 they'll spell out their name in like five different ways, and give maybe some 00:02:25.040 --> 00:02:29.560 known addresses, and they might also give some known Bitcoin addresses that are 00:02:29.560 --> 00:02:30.560 associated with this person. 00:02:30.990 --> 00:02:33.850 Right, so there are Bitcoin addresses on this list, and if you want to send 00:02:33.850 --> 00:02:39.670 Bitcoin to or from these addresses, then, so what Marathon Pool 00:02:39.670 --> 00:02:44.510 was doing was they would essentially filter these transactions, not include these 00:02:44.510 --> 00:02:48.810 transactions into a block. That's how they would comply with this list, right? 00:02:49.070 --> 00:02:52.230 Yeah, but they didn't actually do that. I think they were thinking about doing 00:02:52.230 --> 00:02:56.290 that. And they put some [unclear] message in the block. But we explained that 00:02:56.290 --> 00:02:59.470 back in that episode, because as far as I know, they didn't actually do any 00:02:59.470 --> 00:03:03.950 filtering, but it caused quite a lot of consternations and they backed out of 00:03:03.950 --> 00:03:07.730 that idea. I think they even replaced their CEO, though that may have been 00:03:07.730 --> 00:03:08.590 completely unrelated. 00:03:10.490 --> 00:03:14.530 But anyway, it was enough motivation for him to write this tool. And what this 00:03:14.530 --> 00:03:19.690 tool does is it basically runs a Bitcoin Core full node and a Bitcoin Core full 00:03:19.690 --> 00:03:25.200 node will propose a block. Basically, it just every 10 seconds creates what it 00:03:25.200 --> 00:03:27.620 thinks would be a correct block. It doesn't do the proof of work. It just 00:03:27.620 --> 00:03:32.350 constructs the block. And then when a real block appears, it compares it. It 00:03:32.350 --> 00:03:35.410 looks at which transactions are missing that were expected to be in the block and 00:03:35.410 --> 00:03:41.290 which transactions are not missing. And then for the transactions that are 00:03:41.290 --> 00:03:44.590 missing, it would run it against a bunch of heuristics of why it might be 00:03:44.590 --> 00:03:49.680 missing. Usually it's completely innocent. So for example, a block transaction 00:03:49.680 --> 00:03:55.590 might be very new. Maybe your node has heard about it one second ago. Then 00:03:55.590 --> 00:03:58.670 it's very likely that other nodes have not heard about it yet. So it's not 00:03:58.670 --> 00:04:03.090 surprising that it's in a block, that it's not in a block. Something else that 00:04:03.090 --> 00:04:08.030 tends to happen, especially these days, is that miners will have an accelerator 00:04:08.030 --> 00:04:12.130 service where they will prioritize transactions that... If you look at their 00:04:12.130 --> 00:04:15.870 Bitcoin fees, they should not be in the block, but they are in the block because 00:04:15.870 --> 00:04:19.890 they've paid through credit card or some other way to be included in the block. 00:04:20.450 --> 00:04:24.570 And so basically some of the tools automatically filter some of these things and 00:04:24.570 --> 00:04:29.430 other times you basically wrote a blog post about it, doing it manually, just 00:04:29.430 --> 00:04:31.010 checking out what's going on here. 00:04:31.900 --> 00:04:34.800 Okay, so what is going on here? Why are we discussing this? 00:04:34.980 --> 00:04:39.140 Well, what seems to be going on here is that there are four transactions by 00:04:39.140 --> 00:04:39.860 F2Pool. 00:04:41.130 --> 00:04:41.610 which... 00:04:41.610 --> 00:04:43.030 Transactions by F2Pool? 00:04:43.150 --> 00:04:45.030 Well, transactions not by F2Pool. 00:04:45.610 --> 00:04:48.030 Transactions not included in a block by F2Pool. 00:04:48.110 --> 00:04:48.510 Exactly. 00:04:48.750 --> 00:04:48.850 Right. 00:04:49.170 --> 00:04:53.610 Four of them. And if you look at each four of them, I believe two or three of 00:04:53.610 --> 00:04:57.510 those, there's not a good explanation of why they're not in a block. Could still 00:04:57.510 --> 00:05:02.110 be innocuous, but they're not recent transactions. 00:05:03.250 --> 00:05:08.910 They're not pushed out because other transactions were prioritized. etc. And then 00:05:08.910 --> 00:05:12.530 the explanation that will remain is that they were filtered because they were on 00:05:12.530 --> 00:05:12.950 that list. 00:05:13.070 --> 00:05:14.110 So they are on that list. 00:05:14.270 --> 00:05:16.930 They definitely are on that list. Yeah, that's not the problem. 00:05:17.310 --> 00:05:19.830 Okay, got it. So censorship is upon us. 00:05:20.500 --> 00:05:24.980 Well, yes, but we didn't know for sure, I guess. We could just do the analysis, 00:05:25.060 --> 00:05:28.860 but then there was a tweet by, 00:05:30.920 --> 00:05:36.460 I guess, the person in control of F2Pool. [unclear]? Yes, 00:05:36.460 --> 00:05:41.880 Who says, uh will disable the TX filtering patch for now until the community 00:05:41.880 --> 00:05:44.400 reaches a more comprehensive consensus on this topic. 00:05:44.400 --> 00:05:50.160 So, basically there's a confirmation that he was in fact filtering out OFAC 00:05:51.440 --> 00:05:54.440 transactions in breach of the OFAC list. 00:05:54.440 --> 00:05:58.820 Yes, or at least some of them because it's not clear if he was filtering all of 00:05:58.820 --> 00:06:00.440 them… um 00:06:01.220 --> 00:06:04.120 But where does this patch even come from? Like, is this a patch? 00:06:04.220 --> 00:06:05.020 [unclear]. 00:06:04.300 --> 00:06:06.540 Can I download this patch? Okay. 00:06:06.780 --> 00:06:10.900 No, you'd have to write it yourself. You'd have to do something like, if this 00:06:10.900 --> 00:06:12.280 transaction arrives... 00:06:12.280 --> 00:06:13.800 Bitcoin Core does not offer this patch? 00:06:14.480 --> 00:06:18.660 No, but I guess you can write a patch that keeps things from going into your 00:06:18.660 --> 00:06:21.800 mempool. I don't know if we have a way to get things out of your mempool once 00:06:21.800 --> 00:06:22.220 it's in there. 00:06:24.080 --> 00:06:28.640 Anyways, so Wang Chun F2Pool was using a patch. 00:06:30.340 --> 00:06:34.280 Maybe self-written maybe not to filter these blocks out, no, these transactions 00:06:34.280 --> 00:06:35.400 out of blocks. 00:06:35.400 --> 00:06:35.860 Yes. 00:06:35.860 --> 00:06:39.480 To comply with the OFAC list. And now he's... 00:06:39.480 --> 00:06:42.280 Well, we don't know if it was to comply with the OFAC list, but the transactions 00:06:42.280 --> 00:06:43.560 were on the... 00:06:41.800 --> 00:06:45.080 [unclear] hedging everything so much? It's pretty obvious at this point, right? 00:06:45.100 --> 00:06:46.080 You did the analysis. 00:06:46.160 --> 00:06:48.720 No, because there are some unconfirmed tweets that suggest that... 00:06:48.720 --> 00:06:49.800 And he confirms it on Twitter. 00:06:50.120 --> 00:06:53.200 Yeah, but there are some other unconfirmed screenshots of tweets that suggest 00:06:53.200 --> 00:06:57.000 that motive may have been slightly different. But in any case, we know that these 00:06:57.000 --> 00:06:58.440 transactions were deliberately filtered. 00:06:58.680 --> 00:07:00.620 But what's the alternative motivation? 00:07:00.880 --> 00:07:03.120 Well, it might be that he just doesn't like those particular people. 00:07:03.600 --> 00:07:06.600 He just doesn't like the same people that the US government doesn't like. 00:07:06.760 --> 00:07:06.960 Yeah, exactly. 00:07:07.180 --> 00:07:09.400 Okay, but then still he's filtering transactions. 00:07:09.660 --> 00:07:09.760 Yes. 00:07:09.760 --> 00:07:12.180 Like there's still some form of censorship happening, right? 00:07:12.200 --> 00:07:15.120 Exactly. But there could be two different reasons for censorship, right? One is 00:07:15.120 --> 00:07:18.240 you're afraid of some government, like the US government, making your life 00:07:18.240 --> 00:07:22.140 difficult. And the other could be, well, you think the US government is actually right. 00:07:22.340 --> 00:07:22.620 Okay. 00:07:22.760 --> 00:07:25.940 But we have no idea which of those two is the true motivation. I'm just saying... 00:07:25.860 --> 00:07:26.680 Either is possible. 00:07:26.820 --> 00:07:26.940 Sure. 00:07:27.180 --> 00:07:28.060 Either is problematic. 00:07:28.400 --> 00:07:31.120 Are we talking about this because we should be worried about this? Is your 00:07:31.120 --> 00:07:32.660 opinion that we should be worried about this? 00:07:32.780 --> 00:07:37.180 I think we talked about that in the earlier episode, that I am worried about this 00:07:37.180 --> 00:07:40.480 in the long run. Now, in the short run, it's absolutely not a problem because 00:07:40.480 --> 00:07:43.800 these transactions were just mined by another miner, the next block. 00:07:44.480 --> 00:07:44.920 Yeah. 00:07:45.240 --> 00:07:46.580 Ironically, by a US miner. 00:07:46.920 --> 00:07:50.940 Yeah. Maybe it's a bit much to go over this whole thing again. Again, we 00:07:50.940 --> 00:07:53.020 discussed it in episode 37, you said? 00:07:53.420 --> 00:07:53.880 Yes. 00:07:53.880 --> 00:07:58.660 Yeah so that's what we discuss I guess in depth how worried we are about it. 00:07:58.660 --> 00:08:04.660 Anyways, um short term. So now it's turned off. I guess the 00:08:04.660 --> 00:08:07.900 other thing maybe worth mentioning is so this is something that… 00:08:07.900 --> 00:08:12.000 So the fact that we were able to detect this at all is because you know of all 00:08:12.000 --> 00:08:16.400 this tooling it's it's not that obvious normally because transactions you know 00:08:16.400 --> 00:08:20.920 sometimes they appear in a block sometimes they don't. So that's pretty cool that 00:08:20.920 --> 00:08:22.380 we have the tech to detect it. 00:08:22.540 --> 00:08:27.200 The impact is pretty minor. Another relevant episode perhaps to listen to in this 00:08:27.200 --> 00:08:32.420 context is the episode we did on Stratum V2 because Stratum V2 is kind of a 00:08:32.420 --> 00:08:35.620 solution for this problem if we consider it a problem, right? 00:08:36.050 --> 00:08:40.010 Yeah, what Stratum V2 does that's relevant here is that it delegates the 00:08:40.010 --> 00:08:43.890 responsibility of putting things into a block, not to the mining pool, which 00:08:43.890 --> 00:08:48.390 tends to be quite large. You know, there's two pools that are 51% roughly of all 00:08:48.390 --> 00:08:54.270 the hash power, but it delegates it to individual miners. So, and that's far more of them. 00:08:56.410 --> 00:09:01.930 Yeah, so we discussed that in episode 80. Okay, this was a long intro. I guess 00:09:01.930 --> 00:09:07.720 the reason this is worth bringing up is because, I mean, it seems... This is kind 00:09:07.720 --> 00:09:13.520 of the thing that Bitcoin developers and journalists maybe as well sometimes have 00:09:13.520 --> 00:09:17.640 been like talking about and warning about for many years. And this is sort of the 00:09:17.640 --> 00:09:21.940 first time it's actually happening. So there's actually a reason now. 00:09:22.080 --> 00:09:27.250 If you go through, you know, this, if you just assume a slippery slope, which is 00:09:27.250 --> 00:09:30.470 always a problematic type of argument. But if you do, then the ultimate outcome 00:09:30.470 --> 00:09:33.850 of this is you're back to PayPal because all transactions have to be KYC'd and 00:09:33.850 --> 00:09:37.350 permissioned before they go into a block. Now, we're nowhere near that. But does 00:09:37.350 --> 00:09:38.590 this make sense to worry about this? 00:09:39.270 --> 00:09:43.370 Right. It is sort of a first step in that direction. And it's interesting to see 00:09:43.370 --> 00:09:47.610 how things will play out, I guess. So the first step we now saw is that Wang Chun 00:09:47.710 --> 00:09:53.430 disabled his patch. But yeah, it's an event 00:09:53.430 --> 00:09:58.110 in that sense. Like it's a... beginning of something that could go in a very 00:09:58.110 --> 00:10:03.580 wrong direction even though it's only a very small step right now right is this 00:10:03.580 --> 00:10:08.180 are we done with this This was this was the intro to our Bitcoin Core 27— Wait, 00:10:08.180 --> 00:10:12.680 Where are we? 26 episode. Okay, let's talk about Bitcoin Core 26 then. 00:10:12.710 --> 00:10:13.830 Yes. 00:10:14.750 --> 00:10:19.550 First of all, I think everyone knows this by now. Actually, I'm not even going to 00:10:19.550 --> 00:10:23.090 ask you about this anymore. I'll just preface this. So the way it works, Bitcoin 00:10:23.090 --> 00:10:27.870 Core releases a new version of the software every six months. And that means that 00:10:27.870 --> 00:10:33.310 every new feature that was done within these six months is in Bitcoin Core. 00:10:33.650 --> 00:10:39.170 And that means that's a new release. There is not a new release because there is 00:10:39.170 --> 00:10:41.970 a new feature. There's just a new release and whatever is new is new. 00:10:42.510 --> 00:10:46.590 That's right. Yes, exactly. So yeah, so there are no like things that must be 00:10:46.590 --> 00:10:49.530 finished before the deadline uh whatever is ready is ready. 00:10:49.530 --> 00:10:55.250 Right, so the last release was about half a year ago apparently. Right at this 00:10:55.250 --> 00:10:57.730 point where are we in the release process? 00:10:57.730 --> 00:11:02.070 There have been two release candidates as far as I know. The second candidate 00:11:02.070 --> 00:11:05.870 does not have many problems so maybe it's the last one. Maybe there'll be another 00:11:05.870 --> 00:11:07.090 one… um 00:11:07.090 --> 00:11:12.080 Right, so potentially the new Bitcoin Core release could be announced released 00:11:12.080 --> 00:11:12.860 any day now. 00:11:12.860 --> 00:11:13.680 Exactly. 00:11:13.680 --> 00:11:14.200 Okay. 00:11:14.200 --> 00:11:19.560 Or maybe a few weeks. Um, what's interesting perhaps is that there is a testing 00:11:19.560 --> 00:11:23.380 guide now every release there is always a testing guide but this one apparently 00:11:23.380 --> 00:11:27.620 has had some extra love and attention so if you've ever wanted to test a release 00:11:27.620 --> 00:11:32.720 you should look for the uh I think if you google Bitcoin Core 26 release testing 00:11:32.720 --> 00:11:35.180 guide you'll find it and hopefully it'll be in our show notes. 00:11:35.580 --> 00:11:38.280 Who is this for? This is for developers, I would assume. 00:11:38.460 --> 00:11:42.440 I would say a little bit lower barrier to entry than being a developer. Anybody 00:11:42.440 --> 00:11:46.140 who can download a piece of software and carefully follow up instructions. 00:11:46.460 --> 00:11:47.580 So what are you testing? 00:11:47.880 --> 00:11:52.060 You're testing things that have changed. So there's all the features that we're 00:11:52.060 --> 00:11:54.780 talking about, but there's also lots of smaller changes and the testing guide 00:11:54.780 --> 00:11:58.560 will basically take you through some of the changes and how you might go about 00:11:58.560 --> 00:12:02.550 testing them. Of course, you should also test things in a way that's not in the guide. 00:12:02.550 --> 00:12:07.170 How would you go about testing them? Like, what what can you give an example of 00:12:07.170 --> 00:12:08.370 what we're talking about here? 00:12:08.370 --> 00:12:12.170 Yeah well I guess we can do that when we cover the the actual changes. 00:12:12.170 --> 00:12:14.810 Okay, sure. Do you want to get into the actual changes? 00:12:14.810 --> 00:12:15.590 Sure. 00:12:15.590 --> 00:12:20.850 Okay, so the actual change so what we did. Well, mostly Sjors to be honest, is 00:12:20.850 --> 00:12:25.130 you picked out a couple of features in this new release that are 00:12:25.550 --> 00:12:27.110 noteworthy 00:12:29.690 --> 00:12:34.410 Even more like you picked out the most noteworthy of the most noteworthy changes 00:12:34.410 --> 00:12:35.430 right? 00:12:35.430 --> 00:12:37.750 Uh I just picked the ones that I thought were cool. 00:12:37.750 --> 00:12:42.090 Okay, so the first one oh yeah and we mentioned some of them in our previous 00:12:42.090 --> 00:12:45.590 episode actually because in the previous episode which I guess by now is two 00:12:45.590 --> 00:12:50.690 months ago we did mention some new inclusions in Bitcoin Core or you did already 00:12:50.690 --> 00:12:56.570 so we'll sort of repeat these for whoever missed that episode or just to give a 00:12:56.570 --> 00:13:00.910 complete picture. So the first one is peer-to-peer transport encryption. 00:13:01.330 --> 00:13:01.910 That's right. 00:13:02.450 --> 00:13:05.410 What's the BIP number for that again? Do you remember? Do you know? 00:13:06.160 --> 00:13:06.480 No. 00:13:06.540 --> 00:13:09.120 It's not BIP-151, right? That one was replaced? 00:13:09.440 --> 00:13:12.940 No, it's a new one. It's peer-to-peer encryption. So we did a whole episode on 00:13:12.940 --> 00:13:18.210 this, episode 77. That really explains why you want to do this. But the short 00:13:18.210 --> 00:13:22.150 version is that nodes will encrypt their traffic between each other. So that 00:13:22.150 --> 00:13:25.990 especially internet providers cannot simply just listen to what you're doing. 00:13:27.590 --> 00:13:31.770 This is actually very easy to test. It's also something that's not on by default. 00:13:31.930 --> 00:13:36.370 But as part of testing you might want to turn that on. So roughly the way you 00:13:36.370 --> 00:13:39.910 would test this is you download Bitcoin Core, the new version. You turn this 00:13:39.910 --> 00:13:45.790 feature on by changing the configuration setting. And then your friend 00:13:45.790 --> 00:13:51.030 also downloads Bitcoin Core, also turns this feature on. And now you try to 00:13:51.030 --> 00:13:54.750 connect to them. So in Bitcoin Core normally it automatically finds peers, but 00:13:54.750 --> 00:13:59.910 you can manually say, hey, please connect to this IP address. And then you can 00:13:59.910 --> 00:14:04.290 actually get something called a session ID. That's probably, it should be in the 00:14:04.290 --> 00:14:08.750 instructions. But basically you'll be able to see a number just like with Signal. 00:14:09.220 --> 00:14:12.880 A long number. And if you compare that long number with what your friend sees as 00:14:12.880 --> 00:14:17.140 a long number, then you know that you are directly connected to them. There's not 00:14:17.140 --> 00:14:21.500 a man in the middle. So that's the kind of thing you can test. And it'd be very 00:14:21.500 --> 00:14:23.760 worrying if the number was different. That would indicate a bug. 00:14:24.240 --> 00:14:24.680 Right. 00:14:24.680 --> 00:14:27.060 Or somebody spying on you. But probably a bug. 00:14:27.220 --> 00:14:30.840 Okay, well, let's linger here a little bit because now you spoke about testing 00:14:30.840 --> 00:14:36.220 and we did discuss it in previous episodes, but still. So right now, Bitcoin Core 00:14:36.220 --> 00:14:36.840 nodes. 00:14:38.630 --> 00:14:41.870 They're part of the peer-to-peer network, so they communicate with each other, 00:14:41.990 --> 00:14:46.550 which specifically means they send transactions and blocks to each other. And 00:14:46.550 --> 00:14:52.250 right now they do that over an unencrypted channel. It's just plain text. It's 00:14:52.250 --> 00:14:58.110 just plain information, right? So that means that internet 00:14:58.110 --> 00:15:01.870 service providers can see exactly which transactions and blocks you're sending. 00:15:02.050 --> 00:15:06.820 And I guess the main problem is that this would allow ISPs… to sort of see where 00:15:06.820 --> 00:15:08.420 transactions originate. 00:15:08.420 --> 00:15:12.480 Yeah I'd say that's one problem. And the other is it makes censorship easier 00:15:12.480 --> 00:15:15.800 because if it's very easy to detect that it's a Bitcoin node it's also very easy 00:15:15.800 --> 00:15:19.840 to block it now that's still easy with this encryption in place for other reasons 00:15:19.840 --> 00:15:24.560 but having encryption it makes it one step easier to to get around censorship. 00:15:24.840 --> 00:15:26.920 Okay, that… 00:15:28.200 --> 00:15:32.700 Yeah that's that's basically it right? That covers this. Okay so this is now in 00:15:32.700 --> 00:15:34.480 Bitcoin Core but it's optional. 00:15:34.480 --> 00:15:35.140 Yes. 00:15:35.140 --> 00:15:35.660 So you can 00:15:37.330 --> 00:15:41.990 switch it on and it's a preferential or did you just explain it is the 00:15:41.990 --> 00:15:44.510 preferential seeking of other nodes that do the same thing? 00:15:44.510 --> 00:15:48.950 Yes, no, it's not preferential, but if if it happens to connect to another node 00:15:48.950 --> 00:15:53.440 and it knows that it has this feature it will use it. But it's not preferential. 00:15:53.720 --> 00:15:57.900 Okay, so it still connects to other nodes randomly, but they will first sort of 00:15:57.900 --> 00:15:59.880 try, hey, are you using encryption? 00:16:00.100 --> 00:16:02.940 No, they will only try if they think the other side can use it. 00:16:03.280 --> 00:16:07.920 Oh, so how would my node think that your node is using encryption? 00:16:08.100 --> 00:16:12.880 So we talked about, I think in episode two or three, we talked about how nodes 00:16:12.880 --> 00:16:17.440 bootstrap and learn about other nodes. So they learn about nodes by having a list 00:16:17.440 --> 00:16:21.330 of IP addresses to connect to. But in addition to those IP addresses, there's 00:16:21.330 --> 00:16:26.810 also some metadata of which features these nodes support. So in your long address 00:16:26.810 --> 00:16:29.930 book of potential nodes to connect to is information like, is this a prune node 00:16:29.930 --> 00:16:34.630 or a full node? Does it have specific bloom filters or whatever filters you want? 00:16:34.890 --> 00:16:40.650 And as of now, it also tracks whether the node supports V2 transport. So if 00:16:40.650 --> 00:16:44.780 your address book says that this other node supports that new feature, which 00:16:44.780 --> 00:16:49.400 could be a lie, but at least that information would be there. Then it'll try that 00:16:49.400 --> 00:16:53.900 first. And if it fails, just tries the V1 connection. Now, I guess in the future, 00:16:53.920 --> 00:16:58.560 we might turn that around and just always try the V2 and then fall back to V1 if 00:16:58.560 --> 00:16:59.080 it doesn't work. 00:16:59.360 --> 00:17:03.200 Yeah, why wouldn't you just always try it? Just because it's extra data to 00:17:03.200 --> 00:17:06.840 communicate? Like this extra try? Like, why wouldn't you just by default first 00:17:06.840 --> 00:17:07.680 try encrypted? 00:17:10.000 --> 00:17:15.550 Because if you first try encrypted... and the other side does not support it, the 00:17:15.550 --> 00:17:19.370 other side will hang up on you. So you have to connect again, which is not the 00:17:19.370 --> 00:17:22.170 end of the world, but right now the majority of the network doesn't support it, 00:17:22.250 --> 00:17:24.750 so that means all of your connections would fail and you'd retry. 00:17:25.420 --> 00:17:25.940 I see. 00:17:26.240 --> 00:17:29.660 But I don't know if that's a big enough deal in the long run. So it might be 00:17:29.660 --> 00:17:30.800 turned around. Just try it. 00:17:31.240 --> 00:17:35.240 Yeah, I would assume eventually the goal is that everyone would use this, right? 00:17:35.620 --> 00:17:37.880 Are there any downsides to using this? 00:17:38.200 --> 00:17:41.800 Well, there is now because it's too new. So if something goes wrong, your node 00:17:41.800 --> 00:17:46.820 might simply fail to connect or get hung up on by all of its peers and you don't 00:17:46.820 --> 00:17:49.660 get the latest blocks, right? So right now it's not safe yet. 00:17:51.280 --> 00:17:55.140 But in the long run, I don't think there's any downside. It was designed to not 00:17:55.140 --> 00:17:59.500 have downsides, in the sense that it's actually even a little bit faster than the 00:17:59.500 --> 00:18:03.920 original protocol. You'd think it'd be slower because it's encrypted, but the 00:18:03.920 --> 00:18:08.120 original protocol uses checksums to make sure that the messages are correct, and 00:18:08.120 --> 00:18:12.960 those checksums use SHA-256, which is very slow, and the new algorithm uses a 00:18:12.960 --> 00:18:17.480 quicker checksum. So it's better in, hopefully in every way, if it's not broken. 00:18:17.720 --> 00:18:21.660 Right. So how, if I download Bitcoin Core 26, how do I switch this on? 00:18:21.900 --> 00:18:26.960 You go into your bitcoin.conf settings file, and then you turn on, I think you 00:18:26.960 --> 00:18:32.260 enter v2transport=1. But it'll be in there, either the release notes or the 00:18:32.260 --> 00:18:32.760 testing guide. 00:18:33.060 --> 00:18:38.430 Right. All right, moving on to the next point. AssumeUTXO was 00:18:38.430 --> 00:18:42.550 implemented for signet, testnet? Not mainnet, right? 00:18:42.770 --> 00:18:43.190 That's right. 00:18:43.470 --> 00:18:45.770 Okay, so what is AssumeUTXO again? 00:18:45.990 --> 00:18:51.990 Well, we covered that in episode 14. So that's quite a while ago. It's basically 00:18:51.990 --> 00:18:56.550 the short version of it is that instead of starting at the Genesis block when you 00:18:56.550 --> 00:18:59.790 start your node and going all the way to the most recent block, which takes a 00:18:59.790 --> 00:19:05.210 long time, you start at a snapshot. And you assume that it's valid. 00:19:05.730 --> 00:19:09.230 And then you go from the snapshot, which might be a few months ago, to the 00:19:09.230 --> 00:19:13.530 present, to the tip. And then once you've done that, you start from the Genesis 00:19:13.530 --> 00:19:16.670 block. And in the background, you check all the blocks. And you make sure that 00:19:16.670 --> 00:19:20.390 you indeed arrive at this snapshot that you assumed initially. 00:19:20.810 --> 00:19:25.050 So the benefit here would be that you can start using the Bitcoin Core node 00:19:25.050 --> 00:19:26.710 before fully syncing? 00:19:27.130 --> 00:19:32.850 Yes. You would basically sync only the last 10% of the blockchain. And you would 00:19:32.850 --> 00:19:37.760 be immediately able to use a wallet, receive coins, send coins. But there's still 00:19:37.760 --> 00:19:42.700 some chance that your starting point was wrong. And what could go wrong then is, 00:19:42.880 --> 00:19:46.680 let's say there's some malicious developers and they just create fake coins. 00:19:47.560 --> 00:19:52.580 Well, now you think you've received coins, but these coins don't actually exist. 00:19:53.010 --> 00:19:55.990 Now that's a really, really expensive attack, right? Because somebody still has 00:19:55.990 --> 00:20:00.250 to make a block with enough proof of work. That is wrong according to all the 00:20:00.250 --> 00:20:05.010 other nodes, but only correct according to you or the list of victims that they 00:20:05.010 --> 00:20:09.350 have. So I don't think that attack is super realistic, but we still want to... 00:20:09.350 --> 00:20:12.550 Plus the developers need to be corrupt, obviously. 00:20:12.950 --> 00:20:17.410 Yeah, so this depends on the distribution mechanism. Right now the idea is that 00:20:17.410 --> 00:20:21.570 the correct block is hard-coded into the source code, so you would indeed have to 00:20:21.570 --> 00:20:27.170 compromise the developers. You could, we could still change that approach. I 00:20:27.170 --> 00:20:30.390 don't know if it'll be changed. But the approach could be that, no, you can just 00:20:30.390 --> 00:20:35.290 use any block and the developers do not bless any of the blocks. Because it's, 00:20:35.490 --> 00:20:39.290 the downside of the developers blessing the blocks is that, well, now if you 00:20:39.290 --> 00:20:40.710 compromise the developers, you're screwed. 00:20:41.310 --> 00:20:43.450 How would you use any block? 00:20:44.110 --> 00:20:48.110 You basically, Bitcoin Core wouldn't care. Like you would just give it a block, 00:20:48.230 --> 00:20:51.550 say, assume this one is correct. You just download that from somebody on the 00:20:51.550 --> 00:20:55.710 internet that you trust. And then you'll find out if it was right or not, but 00:20:55.710 --> 00:20:56.510 it'll take a while. 00:20:56.790 --> 00:20:59.750 Right. I see. And obviously, so... 00:20:59.750 --> 00:21:04.390 So that means there's no centralized group of people to pressure or to corrupt. 00:21:04.650 --> 00:21:04.930 Yep. 00:21:05.070 --> 00:21:08.730 But the downside is you will get scammed left and right because everybody can 00:21:08.730 --> 00:21:10.390 just make their own fake one. 00:21:10.710 --> 00:21:14.930 Yeah. okay interesting so wait which so which version is implemented in Bitcoin 00:21:14.930 --> 00:21:19.590 Core right now the the blessed one okay the developers have blessed it yeah okay 00:21:19.590 --> 00:21:22.690 uh so yeah you mentioned 00:21:22.690 --> 00:21:26.770 And for testnet and signet obviously that's fine right but it's also not there's 00:21:26.770 --> 00:21:28.290 also no theft risk there right? 00:21:28.290 --> 00:21:34.010 It's only on testnet now and signet which is a version of testnet. um so 00:21:34.010 --> 00:21:38.190 yeah so you mentioned even if it would be on mainnet the the attack would be 00:21:38.190 --> 00:21:41.410 expensive because you need to create a fake block and you need to at least in the 00:21:41.410 --> 00:21:45.730 current version corrupt the developers plus it would only work temporarily 00:21:45.730 --> 00:21:49.610 because it's all it's kind of a stop gap until you've actually synced from 00:21:50.620 --> 00:21:54.000 Yeah, basically once you've synced from the Genesis block, the node would crash. 00:21:54.320 --> 00:21:58.880 It's kind of a, yeah, right. It's sort of a solution until, in the meantime. And 00:21:58.880 --> 00:22:03.080 therefore it's obviously also optional. You can just opt to actually wait until 00:22:03.080 --> 00:22:05.860 it's fully synced before you receive any transaction. 00:22:05.860 --> 00:22:08.100 Although in that case, you should just not use the feature. 00:22:08.660 --> 00:22:11.860 Yes, well, that's what I'm saying. The feature is basically optional. 00:22:12.360 --> 00:22:13.800 That's true in general, yes. 00:22:15.060 --> 00:22:19.160 So if you wanted to test this, again, you download Bitcoin Core, then you obtain 00:22:19.160 --> 00:22:23.380 the signet or the Testnet snapshot. There's some links to torrents, I believe. 00:22:24.350 --> 00:22:27.450 And then you just run one command and you'll see it in action. 00:22:28.500 --> 00:22:33.820 Okay, so that's also new in Bitcoin Core 26. On to the third point. 00:22:34.400 --> 00:22:40.370 The third hand-picked selection by Sjors is... Network 00:22:40.370 --> 00:22:46.350 diversity. There's a new upgrade in updated network diversity tools. What's going 00:22:46.350 --> 00:22:46.790 on, Sjors? 00:22:47.130 --> 00:22:51.470 Yeah, so I believe if I understand this feature correctly, and I did not read it 00:22:51.470 --> 00:22:55.610 up in detail, it's been a while, but here's the thing. Bitcoin Core will connect 00:22:55.610 --> 00:23:00.870 to about eight nodes, will make connections outbound to about 8 nodes. 00:23:01.010 --> 00:23:02.610 That's the default? 8 is the default? 00:23:02.810 --> 00:23:07.370 Yes, it might be 9 now. And then other nodes might connect to you, but if you're 00:23:07.370 --> 00:23:12.250 behind a router, etc., then that won't happen. Now those 8 nodes, by default, 00:23:12.350 --> 00:23:18.190 would just be on plain internet. IPv4, IPv6. But if you want to, you can 00:23:18.190 --> 00:23:24.010 also connect to Tor nodes. If you turn Tor on. Now, if you don't do anything, 00:23:24.270 --> 00:23:29.190 you may or may not have a connection to a Tor node. And if you have one and you 00:23:29.190 --> 00:23:33.030 lose that connection because they hang up on you or something goes wrong, then 00:23:33.030 --> 00:23:35.750 you're just going to connect to a new node and maybe it's a Tor node, maybe not. 00:23:36.030 --> 00:23:41.530 Wait, if I'm using Bitcoin Core, which I am. But I haven't explicitly 00:23:41.530 --> 00:23:45.550 made any sort of change to connect through Tor. Can I still connect to other Tor 00:23:45.550 --> 00:23:46.330 nodes? No, right? 00:23:46.530 --> 00:23:48.170 No, you have to turn something on to do that. 00:23:48.270 --> 00:23:49.450 Okay, got it. Okay, go on. 00:23:49.510 --> 00:23:53.130 But once you have turned it on, but you let the Bitcoin Core node automatically 00:23:53.130 --> 00:23:56.910 handle what it connects to, you may or may not have a connection to another Tor 00:23:56.910 --> 00:23:59.890 node. And if you have a connection to another Tor node and you hang up on that 00:23:59.890 --> 00:24:02.740 one, or they hang up on you... maybe you won't have it again. 00:24:03.040 --> 00:24:07.280 Right, so what you're saying is I'm connected to eight nodes. One of them is a 00:24:07.280 --> 00:24:10.660 Tor node because I switched the ping on that allows me to connect to Tor nodes. 00:24:10.980 --> 00:24:16.440 Now this guy's internet, Wi-Fi fails, whatever, I'm disconnected with him. So now 00:24:16.440 --> 00:24:20.400