(summary of a discussion with @sdaftuar and @morcos)
As shown by the discussion of #9375, one issue is the expectation that (existing) peers have that block
messages are never consensus-invalid. This complicates logic significantly, as much of the faster block relay relies on not knowing this ahead of time.
BIP152 essentially introduces an exception. This leads to the question: is this assumption necessary at all?
I don’t think it is. Block validation is expensive, but producing an (invalid) block is very expensive. At the current difficulty, producing a PoW-valid block with state of the art mining hardware requires over 40000 kWh of energy. Using the difficulty at the last checkpoint (which we want to get rid, but it would be replaced by another mechanism for preventing low-difficulty header bloat), it is still 730 kWh. And that’s just for doing a single attack that causes ~seconds of CPU work for network nodes - a persistent one would be prohibitive. Another way of looking at it is that our current protection against this (DoS banning) is likely much cheaper to bypass (get extra IP addresses) than what it already costs to produce invalid blocks.
So I’d like to propose that for blocks, we only DoS ban/disconnect for headers with invalid PoW or building on top of a header with invalid PoW. Specifically, a header building on top of an invalid block (with valid header) would be permitted.
Possible issues that may arise and need separate solutions:
- Header spamming (which is currently prevented by checkpoints, but could be replaced with a different rule - out of scope here).
- Detecting whether all our connections are to nodes that are on different networks. This could be improved by just having rotating connections (is there no issue for this already?) or by marking peers which have a
pindexLastCommonBlock
that over long periods of time remains forked off from out best chain.