Denial-of-service prevention: low-difficulty blocks #534

pull gavinandresen wants to merge 2 commits into bitcoin:master from gavinandresen:DoSorphans changing 13 files +247 −31

gavinandresen commented at 5:07 PM on September 27, 2011: contributor
The attack this prevents: Generate valid low-difficulty blocks (maybe built on top of an early part of the block chain) and send them to a bitcoin node. Before this patch the bitcoin client could store an arbitrary number of them in memory or on disk, in case they later became part of the main chain.

Two checks are added:
1. Blocks before the last blockchain lock-in are rejected, and the peer sending these obviously-not-part-of-the-main-chain blocks it will be disconnected and banned.
2. Blocks must have a plausible proof-of-work. It is impossible for a difficulty 1.0 block to follow a difficulty 1-million block (it would take at least 19 months for difficulty to drop from 1-million to 1). Blocks with too-low proof-of-work are ignored, and peers relaying them are disconnected/banned.
Requiring plausible proof-of-work for orphan blocks or alternate chains foils this attack (you would have to be able to generate valid blocks near current difficulty).
gavinandresen commented at 5:11 PM on September 27, 2011: contributor

Testing: Unless somebody has already written a tool to generate low-difficulty valid-but-orphan blocks, I think we may have to rely on code review and unit tests (unit tests are part of this pull).

(I am working on a tool to generate blocks and transactions for testing, but have more work to do on it)
alexwaters commented at 5:11 PM on September 27, 2011: contributor

Would test-net-in-a-box allow me to create orphaned blocks to test this?
gavinandresen commented at 5:15 PM on September 27, 2011: contributor

You can't use testnet to test this, because testnet doesn't have block-chain lock-in points and there's no way to generate orphan blocks on purpose with too-low difficulty.
ByteCoin commented at 2:20 AM on October 4, 2011: none

What's the justification for having more checkpoints than just the latest?
gavinandresen commented at 3:47 PM on October 5, 2011: contributor

Justification for more than the last checkpoint is it makes it harder for an attacker to waste a newbie's time downloading a long-but-invalid chain.

Pruning some of the checkpoints in the middle is probably a good idea.
Moved checkpoints out of main, to prep for using them to help prevent DoS attacks eb5fff9e16
Orphan block fill-up-memory attack prevention 10fd7f6689
gavinandresen referenced this in commit 43f20bb3c2 on Dec 1, 2011
gavinandresen merged this on Dec 1, 2011
gavinandresen closed this on Dec 1, 2011
coblee referenced this in commit 7637e8ae87 on Jul 17, 2012
rebroad commented at 3:47 AM on June 2, 2013: contributor

I would be curious to know if this network rule change is in line with the Satoshi White Paper on bitcoin.
gmaxwell commented at 4:04 AM on June 2, 2013: contributor

Why are you replying to two year old pulls? This doesn't make the node reject any blocks that it wouldn't already (ultimately) reject.
sipa commented at 9:13 AM on June 2, 2013: member

Indeed, it's not a rule change. It just detects invalid blocks earlier.
DrahtBot locked this on Sep 8, 2021

Contributors

Labels