Bitcoin Eclipse Attacks And How To Stop Them - NADO 17

Aaron van Wirdum Live from Utrecht, this is the Van Wirdum Sjorsnado.

Sjors Provoost Hello.

Aaron van Wirdum Hi Sjors.

Sjors Provoost What's up?

Aaron van Wirdum How are you enjoying the election drama?

Sjors Provoost Oh, thoroughly, yes.

Aaron van Wirdum Be careful what you say because you're definitely going to trigger half of our audience.

Sjors Provoost I don't know.

Aaron van Wirdum Whatever you say.

Sjors Provoost The US has great export products, great cheeseburgers, frappuccinos.

Aaron van Wirdum Nice people.

Sjors Provoost Laptops.

Aaron van Wirdum Great movies.

Sjors Provoost And always good entertainment.

Aaron van Wirdum oh boy okay well let's just skip that you wanted to make a pun about eclipse

Sjors Provoost yes the next solar eclipse is scheduled for december 14th 2020 and it's going to be in latin america

Aaron van Wirdum great so let's talk more about eclipses

Sjors Provoost yes

Aaron van Wirdum for this entire episode

Sjors Provoost that's right

Aaron van Wirdum we're actually gonna do something slightly this is the first time we're doing this i guess right we're gonna discuss a white paper a paper

Sjors Provoost Yeah, we're going to discuss a paper about Eclipse attacks.

Aaron van Wirdum Yes, and the paper...

Sjors Provoost We couldn't come up with a better pun, so apologies. That's all you got from us.

Aaron van Wirdum It's the paper Eclipse attacks on Bitcoin's peer-to-peer network by Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg from Boston University and Hebrew University, MSR Israel.

Sjors Provoost That's right, and it was published in 2015.

Aaron van Wirdum Yeah, so it's a little while ago. We're discussing this because the new Bitcoin Core release will include a new method to prevent eclipse attacks.

Sjors Provoost That's right. And it's actually something that was suggested in that paper. So to give you an idea about the speed of Bitcoin development, sometimes somebody writes a paper in 2015 and then over the years, improvements are made based on that paper and that's still happening.

Aaron van Wirdum Yeah, but this is not the first improvement based on this paper. This is just one of them and this is just the reason we're doing an episode about it now.

Sjors Provoost Correct. A lot of things have already been done.

Aaron van Wirdum Okay, so what are eclipse attacks?

Sjors Provoost So an eclipse attack is when your node is only seeing... your enemy basically your attacker you know your node has connections that it makes to the outside world and there are people who connect to your node and if all those connections are to some evil person then you think you're talking to the whole world but you're actually only talking to one person so that person is eclipsing your view of the world

Aaron van Wirdum exactly yeah bitcoin is a peer-to-peer network so it consists of peers that talk with each other and i think an average regular nodes connects to how many peers

Sjors Provoost usually a node connects to connects to eight peers outbound and it can have up to 117 inbound that's changed maybe a little bit but that's the idea

Aaron van Wirdum right so then the idea is if you control all outbound or inbound nodes

Sjors Provoost both

Aaron van Wirdum both okay so if you control both all inbound and outbound nodes of someone else then you can basically lie to them and they have no other connection to the network am i saying that right

Sjors Provoost that's right so basically you you know you connect to all these nodes because you want to ask them for new transactions and for new blocks and they'll spontaneously give you new transactions and new blocks and so if you know if you're only talking to one person eventually then that person can decide not to give you certain transactions and not to give you certain blocks now they cannot make fake things entirely, right? They can't fake signatures because you're still checking all the consensus rules.

Aaron van Wirdum Sure. But what can they do then? What's the risk? Let's say I'm attacked like this. I'm subject to an eclipse attack.

Sjors Provoost The easiest thing, and that's, I guess, less relevant now because people are more aware of that risk in general, is they can do a double spend attack on you. So let's say you're expecting money from somebody. you're expecting coins from somebody, and you see this transaction appear in your mempool, so in your memory, but it's not yet in a block, and you're happy. But now it turns out that this person is actually sending you that transaction over the wire, but to the outside world, he's sending a very different transaction. And so then a new block arrives, but you're not going to see that block.

Aaron van Wirdum He's sending a conflicting transaction is what you mean. He's sending the same coins to someone else.

Sjors Provoost Yeah, to himself probably.

Aaron van Wirdum Yeah.

Sjors Provoost And so you think you've got this unconfirmed transaction and it's going towards you and you're not seeing any new blocks, but you think, okay, I guess, you know, this is good. It's mine.

Aaron van Wirdum I wouldn't think that's yours.

Sjors Provoost No. So nowadays people know that accepting zero confirmation transactions is a very bad idea and for all sorts of reasons. But this is the easiest thing you can do when you can basically hide what's happening. You can tell this person one thing that you paid them and tell other people another thing.

Aaron van Wirdum Right. So what if I don't trust zero conf?

Sjors Provoost So if you do wait for a confirmation, they can still attack you using an Eclipse attack, but it's going to get a lot more expensive. So they'll have to produce a block, basically, a valid block.

Aaron van Wirdum Right.

Sjors Provoost And then they give you that block and it includes the transaction. So you think it's confirmed. But the outside world is also producing blocks, the normal miners. And they're hiding those normal blocks from you. So now in the outside world, that transaction never happened because there's a longer chain that's not paying you. and you've just accepted their one block or maybe multiple blocks. [unclear] more expensive as they have to produce more blocks.

Aaron van Wirdum Yeah, so the idea is if you're a miner and you want to launch this attack on someone, but you only control 10% of hash power, then usually it wouldn't work because even the blocks you produce with the fake transaction will just be orphans away. But if you also have an eclipse attack, then it could actually work because the person you're attacking doesn't see the competing chain.

Sjors Provoost Yes. And this, of course, reminds us why it's important for Bitcoin to be somewhat expensive because it's really expensive to produce blocks like that. Back in 2015, this would have been cheaper.

Aaron van Wirdum Right.

Sjors Provoost But another thing you can do is because now you think, okay, so they're only going to attack me if the cost of making this fake block... is lower than the amount of money they're scamming you for.

Aaron van Wirdum Which is very unlikely.

Sjors Provoost Right, unless you're buying Teslas or all these fancy cars all the time, you don't have to worry about this, you think. But it turns out they can do something else, which is they can actually try to split miners. So they're trying to scam you, but they're also scamming the miners at the same time. Basically making miners not see each other's blocks. And then you might have one miner producing the block the attacker wants and one miner producing the block that goes to you. And the miners don't even know that this is going on and they're wasting a giant amount of money. And the attacker just robs you of $100. So there's a lot of economic damage, but they still scam you.

Aaron van Wirdum Right. So basically, let's say there are two miners on the network, just to simplify things. Then you launch an eclipse attack on one of them. plus you, Sjors, launch an eclipse attack on me. Then you can have this one miner produce blocks and he doesn't see the blocks of his competitor and you send these blocks of the miner you're attacking to me and therefore we're on sort of a separate network which could be a minority network. So the miner is wasting money and I'm being cheated with fake transactions at the same time.

Sjors Provoost Yes, but the attacker still makes money. So yeah, it's important that the attacker doesn't necessarily have to produce the blocks themselves in order to profit from an Eclipse attack. Right. Now, the good news, I don't know if it's good news, but mining is still somewhat centralized. It's like specialized networks that connect miners. So this is quite difficult to do.

Aaron van Wirdum Yeah, like we don't want to rely on relay networks and these kinds of things.

Sjors Provoost Exactly. But we don't want to rely on that, of course.

Aaron van Wirdum Right.

Sjors Provoost Ideally, you know, it should be impossible to eclipse anyone.

Aaron van Wirdum Right. So luckily, it's getting harder over time. Because we're getting more solutions to make it harder.

Sjors Provoost Exactly. Nodes are becoming a little bit hardened. So I guess in order to understand that, we should explain how this paper proposes that one does an eclipse attack.

Aaron van Wirdum Right. Oh, yeah. I almost forgot about that. Yes. How do you actually do it?

Sjors Provoost Well, how did you used to? The idea that you... There's a couple of ingredients that you need here. One is that what nodes are doing when they start, they try to find other peers. And I think we talked about that before a little bit when we talked about DNS seeds.

Aaron van Wirdum Yeah, a couple episodes ago.

Sjors Provoost Yeah, but basically, you know, when a node has been running for a while, it has a list of addresses that it got from other peers. And it stores them in a file. And when the node restarts... it looks at this file for all the addresses it's heard of and it starts randomly connecting to them. And the idea here is that you try to pollute this file as an attacker. You try to give the node a lot of new addresses that you control.

Aaron van Wirdum Right.

Sjors Provoost Or that just don't exist. That's fine too. and you kind of try to exploit the way that this node picks the addresses. That's sort of at a high level what happens. And so basically the node divides the addresses in buckets. It basically looks at the IP address and finds some patterns in it, like the starting letters of the IP address or the starting numbers of the IP address, and it divides them across buckets that way.

Aaron van Wirdum And I guess buckets are just a different word for lists?

Sjors Provoost Yes.

Aaron van Wirdum Yeah.

Sjors Provoost separate lists and then when it's starting up it just tries to you know pick things from different buckets right i still get confused by the details it doesn't really matter but there's basically a way that it does that and you can exploit that mechanism because the mechanism has or had a bias in it for one thing it tried to take very recent items from the so if you've learned about an address recently it would be slightly more likely to use that and so you could exploit that But the idea is you give the node, you start up a whole bunch of attack nodes and you just feed IP addresses. You connect to the victim node so you can occupy all the inbound connections. That's easy.

Aaron van Wirdum Right.

Sjors Provoost And then you give it a lot of nonsense addresses and a lot of real addresses that are you.

Aaron van Wirdum Yeah.

Sjors Provoost So every time it makes a connection, it either fails because there's nothing there or it connects to you. And eventually it only connects to you.

Aaron van Wirdum Right, so if I would have to simplify this probably by a lot then let's say I have a thousand real IP addresses of other nodes, and then you feed me, I don't know, 10 gazillion fake IP addresses or IP addresses that are yours, and then my nodes start to pick IP addresses, then the odds are I'm just going to pick IP addresses that are either fake or yours, and I'm not going to pick any of the real ones because I'm only picking so many IP addresses.

Sjors Provoost Yeah, and so part of the trick here is that you have a list of IP addresses that you know already, But every time you learn new ones, you start throwing away the old ones you already knew.

Aaron van Wirdum Right, so it's even worse than the sort of random example I gave.

Sjors Provoost Yeah, well, that's the problem. You can just keep giving somebody new addresses and then eventually they won't remember any of their old addresses. So the paper runs a simulation to see how difficult it is to actually overflow all these buckets. Because maybe it might be possible in theory, but maybe it's just too much work. And the paper shows that it's actually not too much work. I think it's like a matter of days that you can flood it.

Aaron van Wirdum Okay, so it's going to take a couple of days to basically fill the buckets, the lists of another node's IP addresses with all of your own IP addresses and fake IP addresses.

Sjors Provoost Yep.

Aaron van Wirdum What then?

Sjors Provoost So then the node is still not really, you know, the node still has connections, still has outbound connections to the real world. So the question is, how can you get rid of those connections? And the trick there is you try to make the node crash in whatever way you can make a node crash.

Aaron van Wirdum What are some ways you can make a node crash?

Sjors Provoost Well, there are hopefully no ways to make a node crash. But this is why it's extremely important to make sure, as a developer, you don't write code that can make a node crash. Because it is an important ingredient in these type of attacks.

Aaron van Wirdum And in other attacks.

Sjors Provoost So whenever there is a bug that allows Bitcoin Core to crash, it's a pretty serious one. But, you know, you can somehow overload its RAM usage. There's been lots of... problems like that but when it crashes and it starts again hopefully usually automatically if you if you've configured a server correctly and when it starts automatically or when it starts it's going to look at that file of peers it knows and it's going to try and connect to them so it's going to look in all these buckets and it's only going to find the attacker right and then the attacker also makes sure that it makes sure it's connecting to you so all your inbound connections are full And then you're just only talking to the attacker. So that's what you need.

Aaron van Wirdum And then the Eclipse attack is in play.

Sjors Provoost Exactly.

Aaron van Wirdum So now are we going to solve it?

Sjors Provoost Yeah. So what are we going to do about it?

Aaron van Wirdum What are we going to do about it?

Sjors Provoost So as we already said, it is a numbers game. You need to give a lot of spam addresses to this node to fill up all the buckets and make sure that it only connects to you. So one very simple solution is just to have more buckets. Another is, you know, what we said, these more recent peers that you are biased towards. One thing you can do is to not have that bias.

Aaron van Wirdum Right. Or reverse that bias.

Sjors Provoost Well, then you just attack it in some opposite way. Whenever there's a bias, that gives you something that you can attack.

Aaron van Wirdum I would imagine it's harder to attack the reversed version of that bias if you prioritize IP addresses you already knew. then it's harder for an attacker to attack you, right?

Sjors Provoost Yes, but if you prioritize old IP addresses that you knew a long time ago, then they might not be there anymore. So you're constantly fail to connect. So there's a trade-off there. If you've recently heard about the IP address, it's probably still out there. So there's a bit of a trade-off. But there is one mitigation that's sort of related to this, which is that if you hear of a new address and you want to replace that, You want to put that in the bucket and therefore take something else out of the bucket. First, you check the address that's already in the bucket. You connect to it. You see if it's still out there. If it's still out there, you don't replace it. So that's called a feeler connection. So what I think a couple of years ago was merged was basically Bitcoin Core every now and then. Looks at that bucket, quickly connects to a node, sees if it's real. and remembers that and then disconnects.

Aaron van Wirdum Right. So that is prioritizing older addresses just in a smarter way.

Sjors Provoost Yes. Yeah. Exactly.

Aaron van Wirdum And this was merged. And what about the previous one? I didn't ask, but is that one merged using more buckets?

Sjors Provoost I don't think so.

Aaron van Wirdum Okay.

Sjors Provoost I don't think using more buckets was merged. Basically, the paper has about 10 suggestions and some of them have been merged. Some of them even before the paper came out because obviously it was an exploitable vulnerability. Right. And some of them much later. Another thing you can do. And that is actually what has been merged a few weeks ago.

Aaron van Wirdum Which will be in the next Bitcoin Core release.

Sjors Provoost Hopefully, yes. Well, yes. Is that when you restart, you try to remember some of the last connections you had. And so that's what it's doing, basically. It remembers, I think, two connections, namely two connections that it only exchanges blocks with. And it tries to reconnect to those. But not too often because there's trade-offs everywhere. But apparently it's not a good idea to always try to reconnect to the same nodes again when you restart. Because for all you know, the reason you crashed in the first place is because one of those nodes was evil.

Aaron van Wirdum Right. Yeah, so yeah, the idea is that, as you explained before, you need to crash a node for a node to start up again and find, well, all of the attack IP addresses in this case. This attack would be countered because you're just connected to some of the same IP address you were already connected to. With the trade-off that maybe the one you're connected to was also the one that crashed you, so you might be crashed again.

Sjors Provoost Yes, exactly, yeah. And I think one of the mitigations for that is that you only try this once. So you connect to the one you were connected to last, but if that goes wrong again, you don't do it again. Right. Now, another thing you can do is not have more buckets, but have more connections, more outbound connections. Because, you know, the more outbound connections you have, the more likely you are to be connecting to honest nodes.

Aaron van Wirdum Yeah, the harder it is for an attacker to control all of the IP addresses you're connected to.

Sjors Provoost Yeah, and you may ask yourself, why wouldn't you do that? Why not just have as many connections as possible?

Aaron van Wirdum Why not have as many connections as possible, Sjors?

Sjors Provoost That's an excellent question.

Aaron van Wirdum Thank you.

Sjors Provoost The problem is that you're exchanging a lot of data, and especially the transactions that are in the mempool. That is very data intense, like gigabytes and gigabytes and gigabytes. So you can't just add more connections without also increasing bandwidth use. And there are some new proposals that we'll probably discuss in future episodes. that will reduce the bandwidth needed to do these mempool synchronizations. And then you can have more connections. So there's an incentive to make this data exchange more efficient.

Aaron van Wirdum Plus, there's the solution that some of the connections you connect to, you don't share mempool stuff, you only connect blocks.

Sjors Provoost That's right.

Aaron van Wirdum I guess that's also one of the solutions mentioned in the paper, isn't it?

Sjors Provoost I believe it is.

Aaron van Wirdum But we sort of already spoiled it in the previous solution.

Sjors Provoost We may have. So one of the ways to have more connections... To have the upside of more connections without the downside of more bandwidth is to only exchange blocks with those extra connections because that happens much less frequently.

Aaron van Wirdum It still costs a little bit of extra bandwidth, but much less.

Sjors Provoost And this again reminds us that you need to wait for confirmations because those connections will tell you about new blocks. They won't tell you about new stuff in a mempool, but that's fine if you wait for confirmations.

Aaron van Wirdum Is there more?

Sjors Provoost Well, I mean, you can always use the Blockstream satellite or something like that as another source of data. Of course, that's not a universal solution, but it is a [unclear].

Aaron van Wirdum It is almost, I think.

Sjors Provoost Well, I mean, specifically you would be trusting Blockstream.

Aaron van Wirdum Yes.

Sjors Provoost But there is an incentive for Bitcoin blocks to be broadcast in general over satellite or AM or from multiple sources. So it's more difficult to eclipse someone because you'd have to eclipse the whole planet. If the signal is coming from a satellite, you want to eclipse somebody who's listening to that satellite and you either have to blow up the satellite connection to them or blow up the satellite itself, which everybody would notice and it'd be in the news and you'd say, hey, there's probably something going on here.

Aaron van Wirdum Sure.

Sjors Provoost Let's see, any other mitigations?

Aaron van Wirdum I like your adversarial mindset though, that you do recognize that that's actually a risk that someone blows up the satellite.

Sjors Provoost Well, I mean, you don't actually physically have to blow it up, I guess. You can just tell people to stop broadcasting to it. One more solution is to have more nodes, basically, that other people don't know are yours. So if you have multiple nodes that you're using for whatever your service is, and you make sure that the outside world doesn't know all of them, then they might try to eclipse one of them, but they forgot to eclipse the other ones.

Aaron van Wirdum Sounds like a good idea to me, Sjors.

Sjors Provoost Yeah.

Aaron van Wirdum But there were like 10 solutions in the paper.

Sjors Provoost Yeah, there were.

Aaron van Wirdum But we didn't cover them all then.

Sjors Provoost No, we didn't. Because in order to cover them all, you would have to describe the attack in much more detail to the point that even though I've read this paper probably two or three times over the past few years, I don't understand all the details, especially these buckets. The way they are filled is rather tedious.

Aaron van Wirdum Right. Fair enough. So yeah, I guess we'll put the paper in the show notes, right?

Sjors Provoost Yes. And there's a website that links to some of the solutions that have been implemented. Although I think the website itself is out of date now.

Aaron van Wirdum What's the website?

Sjors Provoost Well, we'll put it in the show notes because that's not easy to spell out.

Aaron van Wirdum All right. Anything else?

Sjors Provoost No.

Aaron van Wirdum Was this our episode on eclipse attacks?

Sjors Provoost I think so.

Aaron van Wirdum Nice.

Sjors Provoost That's all I've got. Thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.