So as to add to the opposite reply, since Bitcoin Core 24.0, there’s an extra safety carried out in opposition to low-difficulty header spam: header pre-syncing.
To recapitulate, because the headers-first synchronization launched in Bitcoin Core 0.10.0, blocks are by no means downloaded earlier than their headers are identified and verified to have adequate work (which implies: sufficient to inside sooner or later of the lively chain tip, and greater than the preconfigured minimal chain work). This implies we already need not fear about low-difficulty block spam anymore. The blocks are simply not downloaded until they’re a part of a sequence that is confirmed to be adequate.
But, a weaker drawback remained: a peer might begin giving us (a number of) chains of headers that by no means quantity to something beneficial. For the reason that headers are despatched in ahead order, there isn’t any approach to know originally how good the end result will get. The previous answer (checkpoints) is unsatisfactory: it depends on up to date software program with hardcoded overrides on what chain is appropriate. As of Bitcoin Core 26.0, the checkpoints stay, however have not been up to date since 2014. By now, mining has turn into a lot cheaper per hash, that an attacker might realistically begin an assault after the final checkpoint.
Since Bitcoin Core 24.0, a brand new answer has been carried out: headers pre-syncing.
The thought is that the header synchronization (which precedes the block synchronization) is cut up up in two phases:
- In a primary part, header presyncing, headers from a peer are downloaded and verified, however not saved, as a result of we do not but know whether or not they’ll find yourself being adequate. As an alternative, solely a really compact (salted) hash of those headers is stored (in per-peer reminiscence, discarded upon disconnect).
- In a second part, header redownloading, the identical headers are downloaded once more from the identical peer, and in comparison with the saved hash(*). If there’s a match, they’re fed to full header validation, which shops them, and can set off block obtain.
This method comes at a value – the header synchronization is successfully carried out twice, doubling its bandwidth price (which remains to be small in comparison with full block obtain), however removes the final reliance on checkpoints within the codebase. They will seemingly be eliminated in some future model.
(*) A easy hash would not be adequate, as we’d like the flexibility to confirm headers alongside the way in which, not simply the tip. The precise construction consists of a single 1-bit salted hash each ~600 blocks. To compensate for the (extraordinarily) small hash, upon redownloading, there’s a buffer of ~14000 headers which can be downloaded earlier than validation. Provided that all of the ~23 1-bit hashes in these 14000 headers match, then the start of the buffer is fed to validation. This implies each header has some 23 bits checked in opposition to it earlier than validation, which might price an attacker tens of millions of tries to succeed in opposition to.
