WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.220 --> 00:00:10.140 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:10.240 --> 00:00:10.420 Hello. 00:00:11.160 --> 00:00:11.720 Hi Sjors. 00:00:11.960 --> 00:00:12.220 What's up? 00:00:12.560 --> 00:00:15.720 How are you enjoying the election drama? 00:00:16.120 --> 00:00:17.480 Oh, thoroughly, yes. 00:00:17.760 --> 00:00:20.780 Be careful what you say because you're definitely going to trigger half of our 00:00:20.780 --> 00:00:21.200 audience. 00:00:21.420 --> 00:00:21.900 I don't know. 00:00:21.960 --> 00:00:22.980 Whatever you say. 00:00:23.140 --> 00:00:26.980 The US has great export products, great cheeseburgers, frappuccinos. 00:00:27.060 --> 00:00:27.720 Nice people. 00:00:28.160 --> 00:00:28.680 Laptops. 00:00:29.160 --> 00:00:30.080 Great movies. 00:00:30.460 --> 00:00:31.040 And always good entertainment. 00:00:32.450 --> 00:00:37.950 oh boy okay well let's just skip that you wanted to make a pun about eclipse 00:00:37.950 --> 00:00:43.710 yes the next solar eclipse is scheduled for december 00:00:43.710 --> 00:00:46.750 14th 2020 and it's going to be in latin america 00:00:46.750 --> 00:00:50.030 great so let's talk more about eclipses 00:00:50.030 --> 00:00:50.470 yes 00:00:50.470 --> 00:00:51.730 for this entire episode 00:00:51.730 --> 00:00:52.610 that's right 00:00:52.610 --> 00:00:56.770 we're actually gonna do something slightly this is the first time we're doing 00:00:56.770 --> 00:01:00.570 this i guess right we're gonna discuss a white paper a paper 00:01:00.970 --> 00:01:03.330 Yeah, we're going to discuss a paper about Eclipse attacks. 00:01:03.670 --> 00:01:04.550 Yes, and the paper... 00:01:04.550 --> 00:01:08.450 We couldn't come up with a better pun, so apologies. That's all you got from us. 00:01:08.810 --> 00:01:14.610 It's the paper Eclipse attacks on Bitcoin's peer-to-peer network by Ethan 00:01:14.610 --> 00:01:20.250 Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg from Boston 00:01:20.250 --> 00:01:23.970 University and Hebrew University, MSR Israel. 00:01:24.230 --> 00:01:26.150 That's right, and it was published in 2015. 00:01:26.570 --> 00:01:30.590 Yeah, so it's a little while ago. We're discussing this because the new Bitcoin 00:01:30.590 --> 00:01:35.470 Core release will include a new method to prevent eclipse attacks. 00:01:35.710 --> 00:01:40.960 That's right. And it's actually something that was suggested in that paper. So to 00:01:40.960 --> 00:01:43.840 give you an idea about the speed of Bitcoin development, sometimes somebody 00:01:43.840 --> 00:01:48.120 writes a paper in 2015 and then over the years, improvements are made based on 00:01:48.120 --> 00:01:49.740 that paper and that's still happening. 00:01:50.020 --> 00:01:52.840 Yeah, but this is not the first improvement based on this paper. This is just one 00:01:52.840 --> 00:01:55.360 of them and this is just the reason we're doing an episode about it now. 00:01:55.540 --> 00:01:57.140 Correct. A lot of things have already been done. 00:01:57.480 --> 00:01:59.240 Okay, so what are eclipse attacks? 00:01:59.940 --> 00:02:05.580 So an eclipse attack is when your node is only seeing... your enemy basically 00:02:05.580 --> 00:02:09.220 your attacker you know your node has connections that it makes to the outside 00:02:09.220 --> 00:02:12.700 world and there are people who connect to your node and if all those connections 00:02:12.700 --> 00:02:16.720 are to some evil person then you think you're talking to the whole world but 00:02:16.720 --> 00:02:19.880 you're actually only talking to one person so that person is eclipsing your view 00:02:19.880 --> 00:02:20.420 of the world 00:02:20.420 --> 00:02:24.900 exactly yeah bitcoin is a peer-to-peer network so it consists of peers that talk 00:02:24.900 --> 00:02:30.400 with each other and i think an average regular nodes connects to how many peers 00:02:30.400 --> 00:02:36.000 usually a node connects to connects to eight peers outbound and it can have up to 00:02:36.000 --> 00:02:40.540 117 inbound that's changed maybe a little bit but that's the idea 00:02:40.540 --> 00:02:45.720 right so then the idea is if you control all outbound or inbound nodes 00:02:45.720 --> 00:02:46.160 both 00:02:46.160 --> 00:02:51.950 both okay so if you control both all inbound and outbound nodes of someone else 00:02:51.950 --> 00:02:55.910 then you can basically lie to them and they have no other connection to the 00:02:55.910 --> 00:02:57.110 network am i saying that right 00:02:57.110 --> 00:03:01.750 that's right so basically you you know you connect to all these nodes because you 00:03:01.750 --> 00:03:05.670 want to ask them for new transactions and for new blocks and they'll 00:03:05.670 --> 00:03:09.770 spontaneously give you new transactions and new blocks and so if you know if 00:03:09.770 --> 00:03:13.110 you're only talking to one person eventually then that person can decide not to 00:03:13.110 --> 00:03:16.350 give you certain transactions and not to give you certain blocks now they cannot 00:03:16.350 --> 00:03:21.520 make fake things entirely, right? They can't fake signatures because you're still 00:03:21.520 --> 00:03:22.820 checking all the consensus rules. 00:03:22.940 --> 00:03:28.800 Sure. But what can they do then? What's the risk? Let's say I'm attacked like 00:03:28.800 --> 00:03:31.860 this. I'm subject to an eclipse attack. 00:03:32.040 --> 00:03:35.940 The easiest thing, and that's, I guess, less relevant now because people are more 00:03:35.940 --> 00:03:40.980 aware of that risk in general, is they can do a double spend attack on you. So 00:03:40.980 --> 00:03:45.350 let's say you're expecting money from somebody. you're expecting coins from 00:03:45.350 --> 00:03:49.770 somebody, and you see this transaction appear in your mempool, so in your memory, 00:03:49.910 --> 00:03:53.890 but it's not yet in a block, and you're happy. But now it turns out that this 00:03:53.890 --> 00:03:59.870 person is actually sending you that transaction over the wire, but to 00:03:59.870 --> 00:04:05.210 the outside world, he's sending a very different transaction. And so then a new 00:04:05.210 --> 00:04:07.530 block arrives, but you're not going to see that block. 00:04:07.670 --> 00:04:10.710 He's sending a conflicting transaction is what you mean. He's sending the same 00:04:10.710 --> 00:04:12.490 coins to someone else. 00:04:12.650 --> 00:04:13.530 Yeah, to himself probably. 00:04:13.910 --> 00:04:14.010 Yeah. 00:04:14.820 --> 00:04:18.180 And so you think you've got this unconfirmed transaction and it's going towards 00:04:18.180 --> 00:04:21.200 you and you're not seeing any new blocks, but you think, okay, I guess, you know, 00:04:21.400 --> 00:04:23.000 this is good. It's mine. 00:04:23.800 --> 00:04:25.140 I wouldn't think that's yours. 00:04:25.540 --> 00:04:29.400 No. So nowadays people know that accepting zero confirmation transactions is a 00:04:29.400 --> 00:04:32.920 very bad idea and for all sorts of reasons. But this is the easiest thing you can 00:04:32.920 --> 00:04:36.260 do when you can basically hide what's happening. You can tell this person one 00:04:36.260 --> 00:04:39.540 thing that you paid them and tell other people another thing. 00:04:39.760 --> 00:04:43.290 Right. So what if I don't trust zero conf? 00:04:43.510 --> 00:04:47.730 So if you do wait for a confirmation, they can still attack you using an Eclipse 00:04:47.730 --> 00:04:52.600 attack, but it's going to get a lot more expensive. So they'll have to produce a 00:04:52.600 --> 00:04:55.220 block, basically, a valid block. 00:04:55.480 --> 00:04:55.660 Right. 00:04:56.220 --> 00:05:00.560 And then they give you that block and it includes the transaction. So you think 00:05:00.560 --> 00:05:03.880 it's confirmed. But the outside world is also producing blocks, the normal 00:05:03.880 --> 00:05:09.630 miners. And they're hiding those normal blocks from you. So now in the outside 00:05:09.630 --> 00:05:12.930 world, that transaction never happened because there's a longer chain that's not 00:05:12.930 --> 00:05:18.010 paying you. and you've just accepted their one block or maybe multiple blocks. 00:05:18.210 --> 00:05:21.470 [unclear] more expensive as they have to produce more blocks. 00:05:21.630 --> 00:05:26.810 Yeah, so the idea is if you're a miner and you want to launch this attack on 00:05:26.810 --> 00:05:31.770 someone, but you only control 10% of hash power, then usually it wouldn't work 00:05:31.770 --> 00:05:35.190 because even the blocks you produce with the fake transaction will just be 00:05:35.380 --> 00:05:40.680 orphans away. But if you also have an eclipse attack, then it could actually work 00:05:40.680 --> 00:05:44.760 because the person you're attacking doesn't see the competing chain. 00:05:45.200 --> 00:05:48.700 Yes. And this, of course, reminds us why it's important for Bitcoin to be 00:05:48.700 --> 00:05:52.440 somewhat expensive because it's really expensive to produce blocks like that. 00:05:52.700 --> 00:05:54.320 Back in 2015, this would have been cheaper. 00:05:54.600 --> 00:05:54.700 Right. 00:05:54.900 --> 00:05:58.280 But another thing you can do is because now you think, okay, so they're only 00:05:58.280 --> 00:06:04.220 going to attack me if the cost of making this fake block... is lower than 00:06:04.220 --> 00:06:05.860 the amount of money they're scamming you for. 00:06:06.080 --> 00:06:07.360 Which is very unlikely. 00:06:07.720 --> 00:06:12.100 Right, unless you're buying Teslas or all these fancy cars all the time, you 00:06:12.100 --> 00:06:15.900 don't have to worry about this, you think. But it turns out they can do something 00:06:15.900 --> 00:06:21.770 else, which is they can actually try to split miners. So they're 00:06:21.770 --> 00:06:25.550 trying to scam you, but they're also scamming the miners at the same time. 00:06:25.970 --> 00:06:31.160 Basically making miners not see each other's blocks. And then you might have one 00:06:31.160 --> 00:06:35.760 miner producing the block the attacker wants and one miner producing the block 00:06:35.760 --> 00:06:36.480 that goes to you. 00:06:37.730 --> 00:06:41.330 And the miners don't even know that this is going on and they're wasting a giant 00:06:41.330 --> 00:06:46.820 amount of money. And the attacker just robs you of $100. So there's a lot of 00:06:46.820 --> 00:06:49.560 economic damage, but they still scam you. 00:06:49.780 --> 00:06:53.800 Right. So basically, let's say there are two miners on the network, just to 00:06:53.800 --> 00:06:58.360 simplify things. Then you launch an eclipse attack on one of them. plus 00:06:58.360 --> 00:07:04.190 you, Sjors, launch an eclipse attack on me. Then 00:07:04.190 --> 00:07:09.390 you can have this one miner produce blocks and he doesn't see the blocks of his 00:07:09.390 --> 00:07:14.210 competitor and you send these blocks of the miner you're attacking to me and 00:07:14.210 --> 00:07:17.750 therefore we're on sort of a separate network which could be a minority network. 00:07:18.030 --> 00:07:23.650 So the miner is wasting money and I'm being cheated with fake transactions at the 00:07:23.650 --> 00:07:24.070 same time. 00:07:24.270 --> 00:07:28.410 Yes, but the attacker still makes money. So yeah, it's important that the 00:07:28.410 --> 00:07:31.750 attacker doesn't necessarily have to produce the blocks themselves in order to 00:07:31.750 --> 00:07:35.730 profit from an Eclipse attack. Right. Now, the good news, I don't know if it's 00:07:35.730 --> 00:07:38.890 good news, but mining is still somewhat centralized. It's like specialized 00:07:38.890 --> 00:07:42.250 networks that connect miners. So this is quite difficult to do. 00:07:42.490 --> 00:07:45.750 Yeah, like we don't want to rely on relay networks and these kinds of things. 00:07:46.030 --> 00:07:47.930 Exactly. But we don't want to rely on that, of course. 00:07:48.230 --> 00:07:48.350 Right. 00:07:48.650 --> 00:07:51.350 Ideally, you know, it should be impossible to eclipse anyone. 00:07:52.430 --> 00:07:57.500 Right. So luckily, it's getting harder over time. Because we're getting more 00:07:57.500 --> 00:07:59.140 solutions to make it harder. 00:07:59.660 --> 00:08:03.160 Exactly. Nodes are becoming a little bit hardened. So I guess in order to 00:08:03.160 --> 00:08:07.600 understand that, we should explain how this paper proposes that one does an 00:08:07.600 --> 00:08:08.160 eclipse attack. 00:08:08.660 --> 00:08:13.260 Right. Oh, yeah. I almost forgot about that. Yes. How do you actually do it? 00:08:13.830 --> 00:08:18.170 Well, how did you used to? The idea that you... There's a couple of ingredients 00:08:18.170 --> 00:08:24.130 that you need here. One is that what nodes are doing when they start, 00:08:24.130 --> 00:08:29.730 they try to find other peers. And I think we talked about that before a little 00:08:29.730 --> 00:08:31.150 bit when we talked about DNS seeds. 00:08:31.530 --> 00:08:33.310 Yeah, a couple episodes ago. 00:08:33.550 --> 00:08:36.910 Yeah, but basically, you know, when a node has been running for a while, it has a 00:08:36.910 --> 00:08:40.770 list of addresses that it got from other peers. And it stores them in a file. And 00:08:40.770 --> 00:08:45.940 when the node restarts... it looks at this file for all the addresses it's heard 00:08:45.940 --> 00:08:51.380 of and it starts randomly connecting to them. And the idea here is that you 00:08:51.380 --> 00:08:57.360 try to pollute this file as an attacker. You try to give the node a lot 00:08:57.360 --> 00:08:59.560 of new addresses that you control. 00:08:59.880 --> 00:09:00.400 Right. 00:09:00.520 --> 00:09:05.790 Or that just don't exist. That's fine too. and you kind of try to exploit the way 00:09:05.790 --> 00:09:10.050 that this node picks the addresses. That's sort of at a high level what happens. 00:09:10.390 --> 00:09:15.920 And so basically the node divides the addresses in buckets. It basically 00:09:15.920 --> 00:09:20.430 looks at the IP address and finds some patterns in it, like the starting letters 00:09:20.430 --> 00:09:24.030 of the IP address or the starting numbers of the IP address, and it divides them 00:09:24.030 --> 00:09:25.270 across buckets that way. 00:09:25.450 --> 00:09:28.830 And I guess buckets are just a different word for lists? 00:09:29.330 --> 00:09:29.850 Yes. 00:09:30.110 --> 00:09:30.270 Yeah. 00:09:30.620 --> 00:09:34.580 separate lists and then when it's starting up it just tries to you know pick 00:09:34.580 --> 00:09:38.680 things from different buckets right i still get confused by the details it 00:09:38.680 --> 00:09:42.420 doesn't really matter but there's basically a way that it does that and you can 00:09:42.420 --> 00:09:47.460 exploit that mechanism because the mechanism has or had a bias in it for one 00:09:47.460 --> 00:09:52.120 thing it tried to take very recent items from the so if you've learned about an 00:09:52.120 --> 00:09:55.940 address recently it would be slightly more likely to use that and so you could 00:09:55.940 --> 00:10:00.740 exploit that But the idea is you give the node, you start up a whole bunch of 00:10:00.740 --> 00:10:06.580 attack nodes and you just feed IP addresses. You connect to the victim node 00:10:06.580 --> 00:10:10.200 so you can occupy all the inbound connections. That's easy. 00:10:10.780 --> 00:10:11.300 Right. 00:10:11.620 --> 00:10:16.700 And then you give it a lot of nonsense addresses and a lot of real addresses that are you. 00:10:17.160 --> 00:10:17.300 Yeah. 00:10:17.440 --> 00:10:20.760 So every time it makes a connection, it either fails because there's nothing 00:10:20.760 --> 00:10:24.920 there or it connects to you. And eventually it only connects to you. 00:10:25.600 --> 00:10:31.030 Right, so if I would have to simplify this probably by a lot then let's say 00:10:31.030 --> 00:10:36.530 I have a thousand real IP addresses of other nodes, and then you feed me, I don't 00:10:36.530 --> 00:10:42.090 know, 10 gazillion fake IP addresses or IP addresses that are yours, and then my 00:10:42.090 --> 00:10:47.150 nodes start to pick IP addresses, then the odds are I'm just going to pick IP 00:10:47.150 --> 00:10:50.490 addresses that are either fake or yours, and I'm not going to pick any of the 00:10:50.490 --> 00:10:53.090 real ones because I'm only picking so many IP addresses. 00:10:53.370 --> 00:10:57.210 Yeah, and so part of the trick here is that you have a list of IP addresses that 00:10:57.210 --> 00:11:01.990 you know already, But every time you learn new ones, you start throwing away the 00:11:01.990 --> 00:11:02.950 old ones you already knew. 00:11:03.530 --> 00:11:07.310 Right, so it's even worse than the sort of random example I gave. 00:11:07.690 --> 00:11:11.490 Yeah, well, that's the problem. You can just keep giving somebody new addresses 00:11:11.490 --> 00:11:15.660 and then eventually they won't remember any of their old addresses. So the paper 00:11:15.660 --> 00:11:20.580 runs a simulation to see how difficult it is to actually overflow all these 00:11:20.580 --> 00:11:25.270 buckets. Because maybe it might be possible in theory, but maybe it's just too 00:11:25.270 --> 00:11:29.530 much work. And the paper shows that it's actually not too much work. I think it's 00:11:29.530 --> 00:11:31.530 like a matter of days that you can flood it. 00:11:32.160 --> 00:11:36.400 Okay, so it's going to take a couple of days to basically fill the buckets, the 00:11:36.400 --> 00:11:41.860 lists of another node's IP addresses with all of your own IP addresses and fake 00:11:41.860 --> 00:11:42.480 IP addresses. 00:11:42.720 --> 00:11:42.940 Yep. 00:11:43.140 --> 00:11:43.480 What then? 00:11:44.060 --> 00:11:48.580 So then the node is still not really, you know, the node still has connections, 00:11:48.900 --> 00:11:52.980 still has outbound connections to the real world. So the question is, how can you 00:11:52.980 --> 00:11:57.400 get rid of those connections? And the trick there is you try to make the node 00:11:57.400 --> 00:12:00.320 crash in whatever way you can make a node crash. 00:12:01.340 --> 00:12:03.460 What are some ways you can make a node crash? 00:12:03.760 --> 00:12:07.120 Well, there are hopefully no ways to make a node crash. But this is why it's 00:12:07.120 --> 00:12:11.220 extremely important to make sure, as a developer, you don't write code that can 00:12:11.220 --> 00:12:15.160 make a node crash. Because it is an important ingredient in these type of attacks. 00:12:15.660 --> 00:12:16.720 And in other attacks. 00:12:17.080 --> 00:12:20.960 So whenever there is a bug that allows Bitcoin Core to crash, it's a pretty 00:12:20.960 --> 00:12:26.220 serious one. But, you know, you can somehow overload its RAM usage. 00:12:26.720 --> 00:12:32.010 There's been lots of... problems like that but when it crashes and it starts 00:12:32.010 --> 00:12:36.150 again hopefully usually automatically if you if you've configured a server 00:12:36.150 --> 00:12:40.990 correctly and when it starts automatically or when it starts it's going to look 00:12:40.990 --> 00:12:45.750 at that file of peers it knows and it's going to try and connect to them so it's 00:12:45.750 --> 00:12:49.470 going to look in all these buckets and it's only going to find the attacker right 00:12:49.630 --> 00:12:54.130 and then the attacker also makes sure that it makes sure it's connecting to you 00:12:54.130 --> 00:12:58.050 so all your inbound connections are full And then you're just only talking to the 00:12:58.050 --> 00:13:00.150 attacker. So that's what you need. 00:13:00.690 --> 00:13:03.790 And then the Eclipse attack is in play. 00:13:04.390 --> 00:13:04.790 Exactly. 00:13:05.310 --> 00:13:07.710 So now are we going to solve it? 00:13:08.430 --> 00:13:10.230 Yeah. So what are we going to do about it? 00:13:10.390 --> 00:13:11.510 What are we going to do about it? 00:13:11.650 --> 00:13:17.370 So as we already said, it is a numbers game. You need to give a lot of spam 00:13:17.370 --> 00:13:22.490 addresses to this node to fill up all the buckets and make sure that it only 00:13:22.490 --> 00:13:27.140 connects to you. So one very simple solution is just to have more buckets. 00:13:27.640 --> 00:13:32.160 Another is, you know, what we said, these more recent peers that you are biased 00:13:32.160 --> 00:13:35.680 towards. One thing you can do is to not have that bias. 00:13:35.960 --> 00:13:38.180 Right. Or reverse that bias. 00:13:38.600 --> 00:13:44.140 Well, then you just attack it in some opposite way. Whenever there's a bias, that 00:13:44.140 --> 00:13:45.560 gives you something that you can attack. 00:13:45.600 --> 00:13:49.780 I would imagine it's harder to attack the reversed version of that bias if you 00:13:49.780 --> 00:13:55.360 prioritize IP addresses you already knew. then it's harder for an attacker to 00:13:55.360 --> 00:13:56.020 attack you, right? 00:13:56.340 --> 00:14:00.120 Yes, but if you prioritize old IP addresses that you knew a long time ago, then 00:14:00.120 --> 00:14:04.340 they might not be there anymore. So you're constantly fail to connect. So there's 00:14:04.340 --> 00:14:07.480 a trade-off there. If you've recently heard about the IP address, it's probably 00:14:07.480 --> 00:14:11.500 still out there. So there's a bit of a trade-off. But there is one mitigation 00:14:11.500 --> 00:14:17.140 that's sort of related to this, which is that if you hear of a new address 00:14:17.140 --> 00:14:22.820 and you want to replace that, You want to put that in the bucket and therefore 00:14:22.820 --> 00:14:26.080 take something else out of the bucket. First, you check the address that's 00:14:26.080 --> 00:14:29.840 already in the bucket. You connect to it. You see if it's still out there. If 00:14:29.840 --> 00:14:33.730 it's still out there, you don't replace it. So that's called a feeler connection. 00:14:34.090 --> 00:14:38.450 So what I think a couple of years ago was merged was basically Bitcoin Core every 00:14:38.450 --> 00:14:43.670 now and then. Looks at that bucket, quickly connects to a node, sees if it's 00:14:43.670 --> 00:14:46.470 real. and remembers that and then disconnects. 00:14:46.610 --> 00:14:50.910 Right. So that is prioritizing older addresses just in a smarter way. 00:14:51.090 --> 00:14:52.130 Yes. Yeah. Exactly. 00:14:52.350 --> 00:14:55.390 And this was merged. And what about the previous one? I didn't ask, but is that 00:14:55.390 --> 00:14:57.090 one merged using more buckets? 00:14:57.510 --> 00:14:58.790 I don't think so. 00:14:58.990 --> 00:14:59.290 Okay. 00:14:59.450 --> 00:15:02.910 I don't think using more buckets was merged. Basically, the paper has about 10 00:15:02.910 --> 00:15:05.890 suggestions and some of them have been merged. Some of them even before the paper 00:15:05.890 --> 00:15:10.370 came out because obviously it was an exploitable vulnerability. Right. And some 00:15:10.370 --> 00:15:16.230 of them much later. Another thing you can do. And that is actually what has been 00:15:16.230 --> 00:15:17.470 merged a few weeks ago. 00:15:17.950 --> 00:15:20.090 Which will be in the next Bitcoin Core release. 00:15:20.210 --> 00:15:25.860 Hopefully, yes. Well, yes. Is that when you restart, you try to 00:15:25.860 --> 00:15:29.700 remember some of the last connections you had. And so that's what it's doing, 00:15:29.780 --> 00:15:34.140 basically. It remembers, I think, two connections, namely two connections that it 00:15:34.140 --> 00:15:39.860 only exchanges blocks with. And it tries to reconnect to those. But not too often 00:15:39.860 --> 00:15:45.130 because there's trade-offs everywhere. But apparently it's not a good idea to 00:15:45.130 --> 00:15:49.430 always try to reconnect to the same nodes again when you restart. Because for all 00:15:49.430 --> 00:15:52.170 you know, the reason you crashed in the first place is because one of those nodes 00:15:52.170 --> 00:15:52.630 was evil. 00:15:52.870 --> 00:15:58.310 Right. Yeah, so yeah, the idea is that, as you explained before, you need to 00:15:58.310 --> 00:16:02.710 crash a node for a node to start up again and find, well, all of the attack IP 00:16:02.710 --> 00:16:06.870 addresses in this case. This attack would be countered because you're just 00:16:06.870 --> 00:16:11.090 connected to some of the same IP address you were already connected to. With the 00:16:11.090 --> 00:16:14.290 trade-off that maybe the one you're connected to was also the one that crashed 00:16:14.290 --> 00:16:16.230 you, so you might be crashed again. 00:16:16.730 --> 00:16:21.590 Yes, exactly, yeah. And I think one of the mitigations for that is that you only 00:16:21.590 --> 00:16:26.120 try this once. So you connect to the one you were connected to last, but if that 00:16:26.120 --> 00:16:30.420 goes wrong again, you don't do it again. Right. Now, another thing you can do is 00:16:30.420 --> 00:16:33.800 not have more buckets, but have more connections, more outbound connections. 00:16:34.770 --> 00:16:37.990 Because, you know, the more outbound connections you have, the more likely you 00:16:37.990 --> 00:16:40.070 are to be connecting to honest nodes. 00:16:40.410 --> 00:16:44.450 Yeah, the harder it is for an attacker to control all of the IP addresses you're 00:16:44.450 --> 00:16:44.890 connected to. 00:16:45.110 --> 00:16:50.260 Yeah, and you may ask yourself, why wouldn't you do that? Why not just have as 00:16:50.260 --> 00:16:51.260 many connections as possible? 00:16:51.460 --> 00:16:54.460 Why not have as many connections as possible, Sjors? 00:16:54.540 --> 00:16:55.460 That's an excellent question. 00:16:55.660 --> 00:16:56.060 Thank you. 00:16:56.240 --> 00:17:01.100 The problem is that you're exchanging a lot of data, and especially the 00:17:01.100 --> 00:17:05.060 transactions that are in the mempool. That is very data intense, like gigabytes 00:17:05.060 --> 00:17:09.200 and gigabytes and gigabytes. So you can't just add more connections without also 00:17:09.200 --> 00:17:13.280 increasing bandwidth use. And there are some new proposals that we'll probably 00:17:13.280 --> 00:17:18.880 discuss in future episodes. that will reduce the bandwidth needed to do these 00:17:18.880 --> 00:17:24.340 mempool synchronizations. And then you can have more connections. So there's an 00:17:24.340 --> 00:17:26.860 incentive to make this data exchange more efficient. 00:17:27.080 --> 00:17:31.600 Plus, there's the solution that some of the connections you connect to, you don't 00:17:31.600 --> 00:17:33.980 share mempool stuff, you only connect blocks. 00:17:34.160 --> 00:17:34.520 That's right. 00:17:34.660 --> 00:17:37.520 I guess that's also one of the solutions mentioned in the paper, isn't it? 00:17:37.700 --> 00:17:38.760 I believe it is. 00:17:38.820 --> 00:17:41.140 But we sort of already spoiled it in the previous solution. 00:17:41.200 --> 00:17:45.970 We may have. So one of the ways to have more connections... To have the upside of 00:17:45.970 --> 00:17:49.310 more connections without the downside of more bandwidth is to only exchange 00:17:49.310 --> 00:17:53.430 blocks with those extra connections because that happens much less frequently. 00:17:54.710 --> 00:17:58.790 It still costs a little bit of extra bandwidth, but much less. 00:17:59.030 --> 00:18:03.130 And this again reminds us that you need to wait for confirmations because those 00:18:03.130 --> 00:18:07.330 connections will tell you about new blocks. They won't tell you about new stuff 00:18:07.330 --> 00:18:10.130 in a mempool, but that's fine if you wait for confirmations. 00:18:10.670 --> 00:18:11.530 Is there more? 00:18:11.870 --> 00:18:17.170 Well, I mean, you can always use the Blockstream satellite or something like that 00:18:17.170 --> 00:18:21.450 as another source of data. Of course, that's not a universal solution, but it is a [unclear]. 00:18:21.470 --> 00:18:23.270 It is almost, I think. 00:18:23.750 --> 00:18:26.110 Well, I mean, specifically you would be trusting Blockstream. 00:18:26.170 --> 00:18:26.450 Yes. 00:18:26.630 --> 00:18:32.610 But there is an incentive for Bitcoin blocks to be broadcast in general over 00:18:32.610 --> 00:18:37.730 satellite or AM or from multiple sources. So it's more difficult to eclipse 00:18:37.730 --> 00:18:39.630 someone because you'd have to eclipse the whole planet. 00:18:41.340 --> 00:18:45.300 If the signal is coming from a satellite, you want to eclipse somebody who's 00:18:45.300 --> 00:18:47.620 listening to that satellite and you either have to blow up the satellite 00:18:47.620 --> 00:18:52.020 connection to them or blow up the satellite itself, which everybody would notice 00:18:52.020 --> 00:18:55.340 and it'd be in the news and you'd say, hey, there's probably something going on here. 00:18:55.680 --> 00:18:55.900 Sure. 00:18:57.550 --> 00:18:59.150 Let's see, any other mitigations? 00:18:59.330 --> 00:19:03.490 I like your adversarial mindset though, that you do recognize that that's 00:19:03.490 --> 00:19:05.990 actually a risk that someone blows up the satellite. 00:19:07.500 --> 00:19:11.160 Well, I mean, you don't actually physically have to blow it up, I guess. You can 00:19:11.160 --> 00:19:16.220 just tell people to stop broadcasting to it. One more solution is to have more 00:19:16.220 --> 00:19:22.180 nodes, basically, that other people don't know are yours. So if you have 00:19:22.180 --> 00:19:28.000 multiple nodes that you're using for whatever your service is, and you make sure 00:19:28.000 --> 00:19:30.900 that the outside world doesn't know all of them, then they might try to eclipse 00:19:30.900 --> 00:19:33.820 one of them, but they forgot to eclipse the other ones. 00:19:34.210 --> 00:19:35.790 Sounds like a good idea to me, Sjors. 00:19:36.110 --> 00:19:36.250 Yeah. 00:19:36.450 --> 00:19:38.230 But there were like 10 solutions in the paper. 00:19:38.850 --> 00:19:39.270 Yeah, there were. 00:19:39.650 --> 00:19:41.190 But we didn't cover them all then. 00:19:41.470 --> 00:19:45.050 No, we didn't. Because in order to cover them all, you would have to describe the 00:19:45.050 --> 00:19:49.330 attack in much more detail to the point that even though I've read this paper 00:19:49.330 --> 00:19:53.750 probably two or three times over the past few years, I don't understand all the 00:19:53.750 --> 00:19:57.230 details, especially these buckets. The way they are filled is rather tedious. 00:19:58.000 --> 00:20:02.260 Right. Fair enough. So yeah, I guess we'll put the paper in the show notes, right? 00:20:02.640 --> 00:20:06.200 Yes. And there's a website that links to some of the solutions that have been 00:20:06.200 --> 00:20:09.120 implemented. Although I think the website itself is out of date now. 00:20:09.540 --> 00:20:10.300 What's the website? 00:20:10.560 --> 00:20:12.980 Well, we'll put it in the show notes because that's not easy to spell out. 00:20:13.260 --> 00:20:14.500 All right. Anything else? 00:20:14.800 --> 00:20:14.980 No. 00:20:15.120 --> 00:20:16.740 Was this our episode on eclipse attacks? 00:20:16.920 --> 00:20:17.400 I think so. 00:20:17.920 --> 00:20:18.240 Nice. 00:20:18.360 --> 00:20:21.320 That's all I've got. Thank you for listening to the Van Wirdum Sjorsnado. 00:20:21.720 --> 00:20:22.420 There you go.