Dao Fork Spoof Attacks
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.
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.
In order to facillitate this network split, the geth team included a special handshake, whereby a node requests its peers’ DAO fork block to check if it’s header contains an extra-data field of “dao-hard-fork”. These extra-data fields are typically used by miners for vanity reasons, but are being co-opted for the hard fork.
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.
Executing the attack is incredibly simple for pro-fork miners
- Don’t upgrade to 1.4.10 (you can check your current version with
- Restart geth with
- Continue to mine as normal
- If you’re lucky enough to get block #1920000, you’ll have initated a network-wide spoof attack
- 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.