5

As I understand, full nodes accept block even if it is not mined on top of most recent block and store it as alternative chain as long as it fullfills protocol rules.

What would happen If one start mining millions (or more) of new versions of block height 10 (based on block 9) and keep sending them to the network? Could this cause full nodes to fill their hard drives and make them inoperational?

In other words - is there a limit for side chains enforced somehow by Bitcoin Core or protocol rules?

Improve this question
3

Full nodes use checkpointing: they decide a past block (and all the blocks before it) to be definitive. Any block relayed to them that'd have happened before that checkpoint would be ignored. See this article for more details.

Improve this answer
2
  • Actually, how does that work? The first checkpoint is at height 11111, so if I'm initially downloading the blockchain, an attacker can feed me an unlimited number of candidates for block 10, and until I get blocks 11-11111 I won't know which of them leads to the checkpointed block, so in the meantime I have to store them all (and I don't think that Bitcoin Core will go back and delete them afterward). Are we just hoping that I will get blocks 11-11111 quickly enough that the effect won't be too severe? – Nate Eldredge Jan 19 '19 at 15:55
  • 1
    In recent versions of Bitcoin Core, headers first synchronisation is used. Your client would download first the headers, checking some consensus rules along the way (PoW, etc..) and also checking checkpoints. This way you know that you are downloading the valid main chain. – alcio Jan 19 '19 at 20:26
1

Your information is outdated: For many years now nodes do not fetch, much less store, blocks which aren't memebers of a candidate for the longest chain according to their headers.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.