Today we start with chapter 7 about Eclipse Attacks.
Just a reminder that you can buy the chapter as a printer friendly PDF or the whole book: Bitcoin: A Work in Progress
An eclipse attack is a type of attack that isolates a Bitcoin node by occupying all of its connection slots to block the node from receiving any transactions and blocks, other than those sent to it by the attacker. This prevents the node from seeing what’s going on in the Bitcoin network, and it potentially even tricks the node into accepting an alternative branch of the Bitcoin blockchain. Although nodes will never accept an invalid transaction or block, an eclipse attack can still cause harm, as we’ll see.
This chapter discusses how this type of attack could be used to dupe users and miners. It also talks about solutions to counter this type of attack, some of which were outlined in the 2015 paper “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network,” which was written by Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg from Boston University and Hebrew University/MSR Israel. Many of the solutions proposed by this paper have gradually been implemented in Bitcoin Core software in the past few years. This chapter also discusses some solutions that weren’t in the paper.
Under normal circumstances, your node connects to the outside world via up to eight so-called “outbound peers.” The outside world can also connect to you, and for that, your node allows a maximum of 117 inbound peers. In the case of an eclipse attack, your node only sees and connects to your attacker. So you might think you’re talking to the whole world, but you’re actually only talking to one person. In other words, that person is eclipsing your view of the world.
The reason you connect to all these nodes is because you want to ask them for new transactions and blocks. Data flows in both directions, no matter if the peer is inbound or outbound. Your peers may spontaneously send you blocks and transactions, and your node will in turn forward them to others. As long as you’re connected to at least one honest peer, you won’t miss out on the latest blocks and transactions.
An eclipse attack occurs if all of the peers you’re connected to are controlled by a single entity, your attacker. Now they decide which blocks and transactions your node gets to see, and you may very well be missing out on the latest and greatest out there.
But why does this matter? They can’t send you an invalid block with a fake signature that makes them a billionaire. Your node still checks all the rules and would never accept that. But what they can do is perform a double-spend attack on you.
So let’s say you’re expecting money from somebody, in this case from your attacker or someone they’re colluding with, and you see their transaction appear in your mempool — which is where valid transactions wait to be confirmed — but it’s not yet in a block.
In practice, victims often know who double-spent them. So, for example, it’s not a good idea to double-spend an exchange if you just uploaded a copy of your passport. The author refers to this as proof-of-prison. This is probably why double-spend attacks are rare, even on altcoins with a much lower mining security budget than Bitcoin (we’ll get to the role of proof-of-work below and next week).
You might consider this payment complete and deliver a product or service for it. But it turns out that, behind your back, they sent an alternative transaction to the rest of the network that doesn’t pay you. This alternative, double-spend transaction gets included in a block, but your attacker hides this block from you. So from your point of view, this transaction is still in the mempool, and you remain oblivious to the fact that you’ll never truly receive these coins.
(The thing that gets double-spent is one or more of the coins that form the input for the transaction. A Bitcoin transaction takes coins as its input and creates new coins as its output. An input can only ever be spent once. When a node sees two transactions that spend the same input, they have to pick one and ignore the other. The same goes for miners, who decide which transaction candidate ends up in a block.)
This is the most straightforward example of an eclipse attack. It’s yet another reason that accepting zero-confirmation transactions is a bad idea. Preventing double-spends is the raison d’être for proof-of-work, so a transaction must be included in a block in order to enjoy the protection of the work in that block, and every block on top of it.
In the days before Bitcoin, the double-spend problem was everywhere, and it was only considered solvable by introducing a trusted third party. For example, when receiving any amount of Chaumian e-cash, the software on your computer would immediately inform your bank that you received the tokens. The bank’s computer would then verify that these tokens were never seen before. Without that step, the same e-cash could’ve been spent to many different recipients.
Here’s a brief explanation of Chaumian e-cash. For a longer explanation and a proposed Bitcoin-backed variation of it, listen to episode 52 of Bitcoin, Explained or the more recent Bitcoin.Review podcast on the topic.