Eclipse Attacks really hurt

Today continues chapter 7 from the book Bitcoin: A Work in Progress.

As we explained, 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. It helps to wait for confirmations.

But even if you do wait for a confirmation, you’re not out of the woods. An eclipse attack is still possible, as we’ll see, but it’ll be a lot more expensive. This is because the attacker has to produce a valid block, and part of what determines the validity of a block is that it contains sufficient proof-of-work.

So let’s say you sold something expensive. Like in the previous example, the attacker first sends you their transaction, and then they send a conflicting transaction to the rest of world, while making sure you never see it. That conflicting transaction gets confirmed, but your attacker doesn’t forward this new block to you. Instead, they mine their own block with the original transaction in it. Your node tells you the transaction is confirmed, and you provide the goods or service.

Meanwhile, the outside world of normal miners keeps producing blocks, and the attacker continuous to hide those normal blocks from you. The attacker won’t bother to produce any new blocks, because they have what they need from you. At some point, they stop the attack, or you figure out what happened and intervene. Either way, your node connects to legitimate peers again. It then learns about this longer chain that continued to grow during the attack. Even though, in this longer chain, you never got paid, your node switches to it anyway. In turn, the coins you received disappear.

A double-spend attack is also possible without an eclipse attack, but it’s far less likely to succeed. First of all, you might notice the conflicting transaction in your own mempool and exercise additional caution before delivering any goods or services. And second, let’s say an attacker controls 10 percent of hash power; their attack would fail 90 percent of the time, because the blocks they produce with the conflicting transaction all become stale.^[When two blocks build on top of the same block, both are equally valid. As miners continue to generate more blocks, they’ll pick one of those blocks to build on top of (usually whichever they saw first). Eventually, the tie is broken and one chain becomes longer. The block that’s now no longer part of the longest chain is called stale. The website keeps track of these events and shows an alert as soon as two blocks appear at the same height. It also keeps track of how many blocks are built on each side, until one side falls behind and becomes stale.]

If you wait for two confirmations, the odds for your attacker drop to 1 percent. This is a good reminder of why it’s important for Bitcoin to be somewhat expensive, so that it’s not too easy to produce blocks on alternative branches that double-spend coins. Back in 2015, when the paper we mentioned above was written, these attacks were a lot cheaper: $5,000–$10,000 per block. So, the attacker is only going to attack you if the cost of making a fake block is lower than the amount of money they’re scamming you for. Note that, in practice, someone can’t just order a tailormade block for their attack, unless they are a miner. Since any double-spend attack would harm Bitcoin’s reputation, which would reduce miner revenue, they aren’t particularly incentivized to facilitate such attacks.

Producing a block costs money, mainly for equipment and electricity. An honest miner recoups this by selling or borrowing against the coins created in the coinbase transaction. This is the first transaction in every block, and it has special rules. The first rule is that, unlike regular transactions, a coinbase transaction doesn’t have inputs. It creates money out of nowhere, but the amount is capped by the sum of the block subsidy (currently 6.25 BTC and halving every four years) and all the fees paid by transactions included in the block. The output side of the transaction sends this to wherever the miner wants, but usually an address managed by a mining pool, which then redistributes it.

Normally, a miner produces a block that builds on top of the most recently mined block that they’re aware of. And the coinbase transaction has a second special rule, enforced by all nodes, which says that it can’t be spent until it has 101 confirmations, i.e. until there are 101 blocks built on top of it. This is called coinbase maturity.

The attacker doesn’t care about the coinbase reward, because they stand to make more from scamming you (hypothetically). Instead of building on top of the most recent block out there, they create a block on top of the last block you know of. And they don’t broadcast this block to the world, so no other miners will mine on top of it. This means their coinbase transaction never reaches maturity, so the costs of producing the block can’t be recouped directly. It makes no economic sense for a miner to do this, unless they directly benefit from the attack… or unless they’re duped, as we explain next week.