WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:19.980 --> 00:00:23.100 Live from Utrecht, this is Bitcoin Explained. 00:00:23.240 --> 00:00:25.180 Hello, and welcome back to Utrecht. 00:00:25.460 --> 00:00:29.640 Thank you, Sjors. This is the first time in a long time that we're recording live 00:00:29.640 --> 00:00:30.580 in Utrecht, I think. 00:00:31.080 --> 00:00:31.380 Yes. 00:00:32.850 --> 00:00:35.350 Something about El Salvador and other places. 00:00:35.710 --> 00:00:36.190 Zurich. 00:00:36.530 --> 00:00:37.370 Zurich, yep. 00:00:37.690 --> 00:00:43.620 Yeah, so we're back. We're back in cloudy, rainy the Netherlands. 00:00:43.960 --> 00:00:46.340 Actually, today it's nice. Half clouded. 00:00:46.800 --> 00:00:48.700 Not compared to El Salvador, though, Sjors. 00:00:49.180 --> 00:00:50.940 I don't know. I haven't been there. 00:00:51.280 --> 00:00:57.020 So today we're going to talk about... You really scraped the bottom of the barrel 00:00:57.020 --> 00:00:57.620 for this one. 00:00:57.960 --> 00:00:58.580 I did? 00:00:59.320 --> 00:01:04.920 We're running out of the main topics and now you're looking in the [unclear] of 00:01:04.920 --> 00:01:10.000 Bitcointalk for remaining stuff that we can discuss in this podcast. 00:01:10.520 --> 00:01:11.120 Can't you? 00:01:11.280 --> 00:01:14.320 That's one way to bring it. The other way would be to say, did you know that 00:01:14.320 --> 00:01:15.300 Bitcoin was attacked? 00:01:16.950 --> 00:01:18.510 Wow, that's a much better angle. 00:01:18.770 --> 00:01:21.270 And that the media is hiding this from us because they haven't been talking about 00:01:21.270 --> 00:01:23.160 it. It's a cover-up. 00:01:23.460 --> 00:01:24.520 Yeah, we have a... 00:01:24.520 --> 00:01:25.140 We're going to bring the truth. 00:01:25.420 --> 00:01:29.020 We're going to bring you the truth on this episode on the attack that was 00:01:29.020 --> 00:01:32.460 happening on Bitcoin. It was the attack of the fake peers. 00:01:32.840 --> 00:01:34.000 The attack of the fake peers, yes. 00:01:34.000 --> 00:01:35.860 It almost sounds like a movie title even. 00:01:36.220 --> 00:01:39.320 Yeah, I mean, there's David Gerard's book, you know, Attack of the 50-foot 00:01:39.320 --> 00:01:43.000 Blockchain. But this is the attack of the fake peers, yep. 00:01:43.500 --> 00:01:48.120 All right, so Sjors. So I think I'm just going to… give you the stage on this 00:01:48.120 --> 00:01:52.660 one. What was the attack? What is the attack of the fake peers? What happened, Sjors? 00:01:53.320 --> 00:01:57.700 Well, it was a cold day in July. So somewhere in July... 00:01:57.700 --> 00:01:59.320 So it must have been in the Netherlands it was cold. 00:01:59.540 --> 00:02:04.400 Exactly. Somewhere in July, what people started noticing, people who are running 00:02:04.400 --> 00:02:10.270 nodes, is that sort of random... people were connecting to them. Now, of course, 00:02:10.330 --> 00:02:13.970 this happens all the time. But these random people that were connecting to them 00:02:13.970 --> 00:02:19.850 would connect to them and then send, I think it was 500 messages. And each of 00:02:19.850 --> 00:02:24.010 those 500 messages would contain 10 addresses that were supposed to represent 00:02:24.010 --> 00:02:25.270 other nodes in the network. 00:02:26.130 --> 00:02:30.770 So when you say addresses, you mean IP— IP addresses in this context? 00:02:31.010 --> 00:02:33.870 Yes, that's right. So they would connect you and say, hey, did you know about 00:02:33.870 --> 00:02:37.970 these 10 IP addresses? And did you know about these 10 IP addresses? And they 00:02:37.970 --> 00:02:42.150 would just do that 500 times, and then they would disconnect. And that's a bit weird. 00:02:42.390 --> 00:02:48.260 Yeah, so maybe before we move on, we should take a small step back, which is we 00:02:48.260 --> 00:02:54.160 discussed this in previous episodes: You're our library guy. So maybe you know 00:02:54.160 --> 00:02:59.240 which episodes these were, but we discussed in previous episodes, how nodes 00:02:59.240 --> 00:03:04.520 essentially bootstrap to the network. That is, how do Bitcoin nodes find other 00:03:04.520 --> 00:03:05.420 Bitcoin nodes, right? 00:03:05.580 --> 00:03:09.740 Yeah, we discussed that in episode 13. And we talked about, yeah, so the node 00:03:09.740 --> 00:03:15.220 starts up and it usually asks, looks at a DNS seed, say, hey, tell me something. 00:03:15.360 --> 00:03:20.510 There's like five or six DNS seeds of people who are... It's not really trusted, 00:03:20.670 --> 00:03:25.370 but it is definitely not untrusted either. They get a list of nodes to connect 00:03:25.370 --> 00:03:29.740 to, and then your node will just randomly try a couple and others and others. 00:03:29.920 --> 00:03:33.740 Yeah, and now you're using the word node, but these are also IP addresses, right? 00:03:34.170 --> 00:03:34.730 Yes. 00:03:34.970 --> 00:03:40.550 Yeah. So you start with a small group of IP addresses. And then from there, the 00:03:40.550 --> 00:03:44.750 nodes you connect to, they will share more IP addresses of other nodes with you. 00:03:44.890 --> 00:03:48.230 And that's how you connect to more nodes. And that's sort of how the network 00:03:48.230 --> 00:03:52.870 forms, right? So there are messages between nodes sharing IP addresses about 00:03:52.870 --> 00:03:53.430 other nodes. 00:03:53.570 --> 00:03:54.130 That's right. 00:03:54.470 --> 00:03:59.170 Right. And it's these messages that you just explained were 00:03:59.270 --> 00:04:03.710 being... Spoofed? Is that the right way to put it? 00:04:03.810 --> 00:04:09.150 Well, the messages are real, but the contents was nonsense. So, indeed, a node 00:04:09.150 --> 00:04:13.290 would connect to you, and they would send you a bunch of addresses, but it turns 00:04:13.290 --> 00:04:19.170 out those addresses were just random numbers. So an IP address is just 00:04:19.170 --> 00:04:25.070 a number 1 to 255, and then another number 1 to 255, etc. 00:04:25.190 --> 00:04:27.270 Four numbers, usually with IPv4. 00:04:28.470 --> 00:04:31.730 And yeah, those numbers were just randomly generated. So if you were to map them 00:04:31.730 --> 00:04:34.230 out, you would see they were all over the spectrum. And that's not actually what 00:04:34.230 --> 00:04:38.890 the internet looks like because a lot of IP addresses are not used at all. And so 00:04:38.890 --> 00:04:44.630 it included IP addresses that just cannot exist. So clearly they were 00:04:44.630 --> 00:04:48.370 artificial IP addresses. And the problem with that is that then the odds of there 00:04:48.370 --> 00:04:53.470 actually being a node there is not that good. Because if you're just making up a 00:04:53.470 --> 00:04:56.030 random IP address, then there might not be a node there. The whole point of 00:04:56.030 --> 00:05:01.690 gossiping the nodes is that you get actual nodes. Because if you could just try 00:05:01.690 --> 00:05:03.450 random IP addresses yourself if you wanted to. 00:05:04.090 --> 00:05:09.650 Right. So there were nodes on the network that were sharing random IP 00:05:09.650 --> 00:05:14.150 addresses with other nodes on the network. And that's what we're defining as an 00:05:14.150 --> 00:05:17.810 attack here because the IP addresses that they were sharing were just random 00:05:17.810 --> 00:05:21.610 numbers and they didn't actually point you to a real Bitcoin node, right? 00:05:21.850 --> 00:05:25.270 Yeah. And apparently, according to the people who did some research on it, it 00:05:25.270 --> 00:05:29.390 happened on a fairly large scale. So these people were connecting to lots and 00:05:29.390 --> 00:05:32.930 lots and lots of nodes in the network, at least to the nodes that are listening. 00:05:33.170 --> 00:05:37.150 Because one of the things is if you're starting a node, you might not be 00:05:37.150 --> 00:05:40.230 listening to the outside world. It depends, especially if you're behind a router. 00:05:40.410 --> 00:05:43.890 It's not always the case. But if your node is listening to the outside world, 00:05:44.070 --> 00:05:49.530 then what it does is it actually tells its peers its own IP address. 00:05:50.090 --> 00:05:53.410 So the first time you connect to another node, you're saying, hey, by the way, 00:05:53.570 --> 00:05:55.870 this is my IP address. Please spread the word. 00:05:56.980 --> 00:05:59.760 Do you say it's yours or do you just give an IP address? 00:05:59.940 --> 00:06:01.420 I think you just give one. 00:06:01.600 --> 00:06:01.860 Right. 00:06:02.160 --> 00:06:07.160 And, you know, the other node doesn't really know. But you can give up to 10. And 00:06:07.160 --> 00:06:10.820 that's kind of the mechanism that this attack is exploiting is kind of saying, 00:06:10.900 --> 00:06:14.320 hello, here's 10 IP addresses. And the usual assumption is if that's a new node, 00:06:14.500 --> 00:06:18.820 then, you know, the first one is probably that node. So they're kind of abusing 00:06:18.820 --> 00:06:23.180 the way that nodes used to introduce themselves to the network. Because once your 00:06:23.180 --> 00:06:27.400 address has been gossiped around, then people can connect to you and give you good stuff. 00:06:27.580 --> 00:06:31.900 All right, so I'm running a listening node. I don't think I actually am, but for 00:06:31.900 --> 00:06:36.540 the... As a matter of examples, Sjors, I'm running a listening node. 00:06:36.740 --> 00:06:37.020 Yeah. 00:06:37.320 --> 00:06:41.600 Now, there is this other node that we just explained that is sharing random IP 00:06:41.600 --> 00:06:46.200 addresses. So it's sharing that with my node, and we just define this as an 00:06:46.200 --> 00:06:50.540 attack. Why are we defining this as an attack? What's the problem for me or for 00:06:50.540 --> 00:06:55.440 my node? How am I... you know, how am I a victim of what's going on? 00:06:55.540 --> 00:07:00.280 Well, it's not a big problem for your node in reality, so it's kind of a mild 00:07:00.280 --> 00:07:05.120 attack, you could say, at least in terms of it's not an attack that would kill 00:07:05.120 --> 00:07:08.720 your node in any way. It would just get these IP addresses, and then, you know, 00:07:08.780 --> 00:07:13.500 we talked about it in earlier episodes, I think. Anyway, when a node gets a list 00:07:13.500 --> 00:07:17.100 of IP addresses, it puts them in a bunch of buckets and shuffles them around and 00:07:17.100 --> 00:07:22.530 makes sure that it doesn't listen too much to, like, the same source. And so, you 00:07:22.530 --> 00:07:25.730 know, you already have lots of IP addresses from earlier, from honest nodes. So 00:07:25.730 --> 00:07:29.870 most likely it won't bother you too much. You might connect to a few nodes that 00:07:29.870 --> 00:07:33.430 don't exist. You know, you're just wasting some of your time, but not a huge amount. 00:07:33.710 --> 00:07:39.590 But I would connect to these IP addresses or would I just notice, would my node 00:07:39.590 --> 00:07:42.250 just notice that these aren't nodes and just disconnect immediately? 00:07:42.920 --> 00:07:45.250 Well, that's, that's, but that process takes time, right? 00:07:45.500 --> 00:07:47.200 Okay, yeah, that's what I'm asking. 00:07:47.350 --> 00:07:51.120 Your node is keeping a list of nodes, of IP addresses that it could potentially 00:07:51.120 --> 00:07:52.800 connect to if it needs more connections. 00:07:53.470 --> 00:07:54.150 Got it. 00:07:54.310 --> 00:07:57.310 And then it'll go through that list that is a useless list, basically. 00:07:57.490 --> 00:08:03.030 Right, so it's wasting some of my resources. It's wasting some of my resources 00:08:03.030 --> 00:08:09.030 because my node is storing IP addresses that aren't real Bitcoin 00:08:09.030 --> 00:08:14.180 node IP addresses. So I guess that's a little bit of waste there. And then once 00:08:14.180 --> 00:08:17.660 in a while, I'll try to connect with the node and there's a little bit of 00:08:17.660 --> 00:08:20.220 bandwidth waste. Yeah. And that's sort of it. 00:08:20.680 --> 00:08:25.280 Yeah. So at the individual level, this is not really, you know, you could call it 00:08:25.280 --> 00:08:28.460 an attack. It's like a kid throwing a little pebble at you. You could tell the 00:08:28.460 --> 00:08:31.280 kid, hey, you're attacking me and you could shoot the kid. But usually we just, 00:08:31.440 --> 00:08:32.900 you know, keep walking. 00:08:33.380 --> 00:08:33.900 Got it. 00:08:34.040 --> 00:08:36.900 And nobody noticed it, right? Most people who are not actively looking at their 00:08:36.900 --> 00:08:40.920 node would have not even know this attack happened. So that's good. 00:08:41.620 --> 00:08:45.580 So then why would an attacker, I think that's the next question, why would an 00:08:45.580 --> 00:08:49.800 attacker even bother then? Because clearly someone was bothering to do that. So 00:08:49.800 --> 00:08:53.160 what is the potential benefit of this type of attack? 00:08:53.360 --> 00:08:58.540 So there's two people who wrote a paper, Matthias Grundmann and Max Baumstark, 00:08:58.620 --> 00:09:03.340 and we'll link to it in the show notes from, I believe, the Karlsruhe Institute 00:09:03.340 --> 00:09:04.000 of Technology. 00:09:06.680 --> 00:09:10.600 And the department is the Institute of Information Security and Dependability. 00:09:10.620 --> 00:09:16.370 And I guess that might give a little hint. So what they're guessing is that this 00:09:16.370 --> 00:09:20.550 attacker was not so much trying to destroy the network as they were trying to map 00:09:20.550 --> 00:09:25.100 the network to get a sense of how well nodes are connected to each other. And the 00:09:25.100 --> 00:09:30.100 reason they can do that is because when you receive these 10 IP addresses, you 00:09:30.100 --> 00:09:33.940 will forward some of them to some of your peers, but not all of them. So you get 00:09:33.940 --> 00:09:37.660 some exponential decay where you send them to your neighbors and their neighbors 00:09:37.660 --> 00:09:43.200 send some of them to their neighbors. And so if you're the attacker and you're 00:09:43.200 --> 00:09:48.200 also just running regular nodes, then eventually you'll hear some of the echo of 00:09:48.200 --> 00:09:53.400 your own attack, basically, because your peers will eventually relay it back to 00:09:53.400 --> 00:09:58.960 you. And by looking at this sort of this echo, you can determine a little bit of 00:09:58.960 --> 00:10:02.620 what the network looks like, the shape of it, how well connected it is, how 00:10:02.620 --> 00:10:03.300 robust it is. 00:10:03.440 --> 00:10:09.060 Right. So in the same way that individual transactions, for example, make their 00:10:09.060 --> 00:10:14.610 way through the network by nodes forwarding the transaction to other nodes, they 00:10:14.610 --> 00:10:19.690 are also forwarding these IP addresses to other nodes. So if you keep track 00:10:20.240 --> 00:10:24.780 of how the IP addresses are shared over the network, you learn something about 00:10:24.780 --> 00:10:29.300 how nodes connect to each other, which nodes connect to each other, in what order 00:10:29.300 --> 00:10:31.000 they connect to each other, that kind of stuff. 00:10:31.280 --> 00:10:32.700 Roughly, though not precisely. 00:10:32.960 --> 00:10:35.700 Yeah, and you can potentially use that 00:10:38.090 --> 00:10:42.050 to analyze the actual transactions as well. So if you want to learn something 00:10:42.050 --> 00:10:44.250 about where transactions originate, for example. 00:10:44.470 --> 00:10:47.770 I don't think you can with this type of attack. That's at least what I've been 00:10:47.770 --> 00:10:51.410 told. But you can get a general sense. At least you can get a general sense of 00:10:51.410 --> 00:10:55.370 the shape or maybe the robustness of the network. So that's useful information 00:10:55.370 --> 00:11:00.530 then if you want to attack in the future, perhaps. Or more likely, my guess would 00:11:00.530 --> 00:11:05.640 be maybe it was just people doing research, some academic research, trying to 00:11:05.640 --> 00:11:07.040 find out what the network looks like. 00:11:07.360 --> 00:11:07.520 Right. 00:11:07.740 --> 00:11:09.540 And maybe they'll publish a paper next year. 00:11:10.060 --> 00:11:15.660 Right. So what it does is it helps you map the network. And for whatever reason 00:11:15.660 --> 00:11:19.700 you want to do that, we don't know that, but it helps you map the network. It 00:11:19.700 --> 00:11:22.540 helps you figure out who's connecting to who. 00:11:22.540 --> 00:11:26.440 Yeah, but there are some defense mechanisms in nodes already to make it not too 00:11:26.440 --> 00:11:31.670 easy to use this information. So for example, one thing is if you're telling a 00:11:31.670 --> 00:11:34.910 node a bunch of IP addresses, it's not immediately going to connect to all of 00:11:34.910 --> 00:11:39.790 them because that would be kind of obvious. And it doesn't relay all of them. And 00:11:39.790 --> 00:11:43.530 there's some time delay in when it relays some of them. So it makes it very 00:11:43.530 --> 00:11:47.450 difficult to say specifically which node connects to which node connects to which node. 00:11:47.650 --> 00:11:53.640 And these are these defense… mechanisms specifically for this type of 00:11:53.640 --> 00:11:54.400 attack then or… 00:11:54.400 --> 00:11:55.920 That's my guess but I'm not sure. 00:11:55.920 --> 00:11:59.600 And have they been in Bitcoin Core for a long time or are they new? 00:11:59.600 --> 00:12:04.500 I think they get incrementally added, I guess, when people do these types of 00:12:04.500 --> 00:12:08.520 attacks then, then people like Greg Maxwell and Pieter Wuille will look at it and 00:12:08.520 --> 00:12:10.260 like maybe we can add this little defense. 00:12:10.260 --> 00:12:15.410 I see. So these are attacks that have been happening more often over the past 00:12:15.410 --> 00:12:16.030 couple of years? 00:12:16.270 --> 00:12:17.930 I think so. Not the specific type of attack. 00:12:18.430 --> 00:12:21.770 But these general types of IP sharing attacks? 00:12:22.010 --> 00:12:24.090 I think just probing the network in weird ways. 00:12:24.450 --> 00:12:24.610 Right. 00:12:25.030 --> 00:12:29.170 But it's not really my area of expertise, so I can't really tell much more about 00:12:29.170 --> 00:12:33.050 that than this vague answer that I just gave you that it does seem that people 00:12:33.050 --> 00:12:34.230 are probing the Bitcoin network. 00:12:34.470 --> 00:12:34.930 Fair enough. 00:12:34.970 --> 00:12:39.090 Often probably just for research, but who knows? There might be some evil army out there. 00:12:41.700 --> 00:12:47.640 So is there a solution? Is there a definitive solution? Is this even a concern 00:12:47.640 --> 00:12:51.240 that developers feel like deserves a solution? 00:12:51.480 --> 00:12:54.700 So there is indeed a countermeasure that's been added. 00:12:56.480 --> 00:13:01.020 Like we said, it wasn't a... Yeah, so that's kind of the cliffhanger we can end 00:13:01.020 --> 00:13:05.140 on. But first, let me explain what the countermeasure is. The countermeasure 00:13:05.140 --> 00:13:10.990 basically says that… And normally, when people are acting nice, they will connect 00:13:10.990 --> 00:13:14.050 to you and they'll send you one IP address, namely their own. And then 00:13:14.050 --> 00:13:17.390 occasionally they'll send you some other IP addresses, but not very frequently. 00:13:17.630 --> 00:13:22.950 And people have measured the average speed. I think it's like 20 times— No, once 00:13:22.950 --> 00:13:26.470 every 20 seconds on average or something like that. And so this defense 00:13:26.470 --> 00:13:27.270 mechanism... 00:13:27.270 --> 00:13:32.470 Once in every 20 seconds, an average node will share an IP address with a peer. 00:13:32.750 --> 00:13:36.170 Yeah, it might be a different number, but anyway, there's some average number. 00:13:36.190 --> 00:13:37.170 Something in that ballpark. 00:13:37.390 --> 00:13:42.570 Yeah. And so you can use that by introducing a sort of a rate limiter. 00:13:43.270 --> 00:13:47.230 So a rate limiter basically says, okay, when a new node connects to me, I'll 00:13:47.230 --> 00:13:51.670 allow it to send me one address immediately. And then I'm going to allow it every 00:13:51.670 --> 00:13:56.480 20 seconds up to one address. So it just tracks how many seconds have gone by, 00:13:56.480 --> 00:14:01.540 and if it's sending too many addresses, it'll just ignore the new ones that go 00:14:01.540 --> 00:14:06.220 over this rate limit. So you don't get punished for it. But this way, when 00:14:06.220 --> 00:14:10.420 somebody connects to you and sends a firehose of addresses to you, you just 00:14:10.420 --> 00:14:11.280 ignore all of them. 00:14:11.360 --> 00:14:11.660 Right. 00:14:11.860 --> 00:14:16.140 Except the first one. Now, there are cases when nodes actually want to receive 00:14:16.140 --> 00:14:19.670 addresses from their peer, and there's a special message from that. So if 00:14:19.670 --> 00:14:23.390 somebody connects to you and you say, please tell me addresses, like give me up 00:14:23.390 --> 00:14:26.990 to 1,000, then, of course, you will not rate limit the response. 00:14:30.020 --> 00:14:33.080 You'll make sure that they can actually give you those addresses. But if it's 00:14:33.080 --> 00:14:34.620 unsolicited, then you rate limit it. 00:14:34.800 --> 00:14:38.040 Sure. So it's rate limited unless you overwrite that limit. 00:14:38.240 --> 00:14:43.040 Yeah, and that pretty much gets rid of this attack. Now, the interesting part is 00:14:43.040 --> 00:14:44.220 that apparently... 00:14:44.220 --> 00:14:44.880 Is this the cliffhanger? 00:14:45.000 --> 00:14:45.880 This is the cliffhanger. 00:14:45.930 --> 00:14:46.210 Nice. 00:14:46.360 --> 00:14:51.900 This fix was added before the attack happened. A few weeks before. 00:14:52.180 --> 00:14:53.640 Or even just one week before. 00:14:53.860 --> 00:14:56.740 So the fix was added in Bitcoin Core. 00:14:57.080 --> 00:15:02.600 Yeah, so not released. It was just in the... No, it wasn't even merged. So it was 00:15:02.600 --> 00:15:03.460 an open pull request. 00:15:03.860 --> 00:15:04.340 Right. 00:15:05.080 --> 00:15:10.330 So that means it proposed change to Bitcoin Core. And it was open. And then I 00:15:10.330 --> 00:15:14.740 think a week later or so that attack happened. And it was then merged like a 00:15:14.740 --> 00:15:20.280 couple of weeks later, but it's been released now in version 22.0. 00:15:20.660 --> 00:15:26.200 Right. So the problem was anticipated. A solution was 00:15:26.200 --> 00:15:31.840 developed. And before the solution was actually deployed, the 00:15:31.840 --> 00:15:33.320 problem was abused. 00:15:33.660 --> 00:15:39.260 Yeah. So it almost sounds like somebody saw the solution and thought, huh, 00:15:39.520 --> 00:15:44.140 maybe I can do this attack. Or perhaps somebody was already planning this attack 00:15:44.140 --> 00:15:48.260 and then thought, oh shit, I'd better do it now because it won't be possible 00:15:48.260 --> 00:15:49.620 anymore soon. 00:15:49.880 --> 00:15:55.840 Yeah, that's an interesting point about open source development in general. Now, 00:15:55.940 --> 00:16:00.400 this is a very innocent example, but we've seen other examples of this. I 00:16:00.400 --> 00:16:04.940 remember back in the Bitcoin Unlimited days, if you remember that, where they had 00:16:04.940 --> 00:16:10.020 this alternative implementation that had a bug in it; then it was basically the 00:16:10.020 --> 00:16:14.980 bug was fixed but before the fix was deployed, 00:16:16.300 --> 00:16:21.820 the bug was exploited and it brought down 00:16:21.820 --> 00:16:25.200 all the Bitcoin Unlimited nodes at that time. 00:16:25.420 --> 00:16:30.160 Yeah, so around 2013 on Bitcoin, something similar didn't happen, but could have 00:16:30.160 --> 00:16:35.520 happened, where I think the OpenSSL library was made, so basically it was made 00:16:35.540 --> 00:16:39.720 stricter in a soft fork by saying, okay, the signatures have to be— I don't know, 00:16:39.720 --> 00:16:43.360 some positive number or not a negative number, some some constraints on the 00:16:43.360 --> 00:16:48.030 signatures— was made because otherwise OpenSSL would be unpredictable or 00:16:48.030 --> 00:16:51.930 something like that. And it was presented as just a nice cleanup soft fork, but 00:16:51.930 --> 00:16:55.670 it was actually also a patch for a security vulnerability where somebody could 00:16:55.670 --> 00:17:01.090 have posted a slightly different kind of signature and caused a fork 00:17:01.090 --> 00:17:04.890 because some nodes would accept it and other nodes would not accept it. 00:17:06.230 --> 00:17:10.910 Yeah, this is a very interesting problem. I think it has happened a few times 00:17:10.910 --> 00:17:16.810 before and it seems like the overall solution from Bitcoin Core developers is to 00:17:16.810 --> 00:17:22.370 sort of pretend that it's not a big deal until people have actually downloaded 00:17:22.370 --> 00:17:26.690 and used the software and then later they'll reveal that it was actually a much 00:17:26.690 --> 00:17:27.390 bigger problem. 00:17:28.560 --> 00:17:32.540 At least in those examples that that seems to have happened. Yeah, and that's of 00:17:32.540 --> 00:17:35.660 course not ideal because in open source development you want to be very 00:17:35.660 --> 00:17:39.680 transparent about things you're changing, because you know, if you're being not 00:17:39.680 --> 00:17:42.920 transparent about fixing a critical bug, then maybe you're also not transparent 00:17:42.920 --> 00:17:47.040 about adding inflation, right? So, so it's, it's delicate balance. 00:17:47.370 --> 00:17:51.030 Well, that's another example, actually. That was also the inflation bug a couple 00:17:51.030 --> 00:17:54.830 of years ago. And that was another example where the fix was presented as 00:17:54.830 --> 00:17:56.270 something very unimportant. 00:17:56.330 --> 00:17:59.530 Well, no, it wasn't presented as something. It was presented as important, but it 00:17:59.530 --> 00:18:03.450 was not the full truth. It was presented as this will crash your node, this bug. 00:18:03.570 --> 00:18:07.890 And we fixed a bug that can crash your node. And that was true. It could crash 00:18:07.890 --> 00:18:12.210 your node. But it could also create inflation, which is a bit more important. And 00:18:12.210 --> 00:18:14.100 that was, of course, not announced. 00:18:14.300 --> 00:18:14.740 Yeah. 00:18:14.980 --> 00:18:17.440 Because somebody could have done that in that window of opportunity. 00:18:18.220 --> 00:18:23.060 It's an interesting problem. Anyways, back to the fake peers attack. The fake 00:18:23.060 --> 00:18:28.120 peers attack happened, as we discussed, after a fix was actually written but not 00:18:28.120 --> 00:18:32.780 deployed yet. But now the fix is deployed. It was deployed in Bitcoin Core 22. 00:18:33.120 --> 00:18:36.860 Yeah, so anybody who's running Bitcoin Core 22 won't have this problem and 00:18:36.860 --> 00:18:39.060 anybody who doesn't still doesn't really have the problem. 00:18:39.800 --> 00:18:43.530 Got it. I think that that covers it all. Sure, sure. 00:18:43.630 --> 00:18:47.770 No, I think so too. So in that case, thank you for listening to Bitcoin 00:18:47.770 --> 00:18:48.450 Explained. 00:18:48.830 --> 00:18:49.290 There you go.