Dao Fork Spoof Attacks

Disclaimer

This article has not been thoroughly peer reviewed. Usually I would wait longer for input for others, however the speed at which the DAO hard fork is being developed and rolled out leaves little room. As such, please wait before drawing final conclusions on the viability of this attack.

Description

In the seconds after the DAO hard fork is applied, there will be a split in the network. A pro-fork miner will broadcast a block that many of its peers believe to be invalid. Those nodes will refuse to relay those blocks and the network will begin to split.

Processing bad blocks is costly, so it would be much quicker to peer up to nodes on the same side of the fork. This is especially true for pro-fork nodes, since they are in the numerical (but not necessarily economic) minority and likely will be for the near future. Until the network split completes, nodes are essentially running spam attacks against each other.

The catch, however, is that miners can choose whatever extra-data field they like – regardless of their position on the fork. So an anti-fork miner could easily include the relevant extra-data, and claim the block its propagating is on the dao-fork. Such a block would be accepted by geth 1.4.10 clients (who aren’t running --oppose-dao-fork and are synced with --fast) and all clients below 1.14.10. The blocks would then be propogated to their peers, who would begin the costlier process of transaction validating and removing peers.

The geth team seems to be concerned enough about this attack, that they included a settings override to stop miners from attempting to spoof the chain. However, miners who do not upgrade to 1.4.10 are more than able to spoof it.

Attack Execution

Executing the attack is incredibly simple for pro-fork miners

Don’t upgrade to 1.4.10 (you can check your current version with geth version)

Restart geth with --extradata="dao-hard-fork"

Continue to mine as normal

If you’re lucky enough to get block #1920000, you’ll have initated a network-wide spoof attack

Solutions

Disable fast sync before block #1920000. In the near future, update geth with a block hash check instead of a extra data check

Extend the handshake to 10 blocks instead of 1. This will make it so that malicious miners will need to execute a 51% attack, rather than just get lucky on block #1920000. This validation is already done while syncing, I’m suggesting it extend to peering as well.