So as to add to the opposite reply, since Bitcoin Core 24.0, there may be a further safety applied towards low-difficulty header spam: header pre-syncing.

To recapitulate, for the reason that headers-first synchronization launched in Bitcoin Core 0.10.0, blocks are by no means downloaded earlier than their headers are recognized and verified to have ample 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 series that is confirmed to be adequate.

But, a weaker downside remained: a peer might begin giving us (a number of) chains of headers that by no means quantity to something beneficial. Because the headers are despatched in ahead order, there isn’t a technique to know firstly 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 out to be 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 applied: 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 section, 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 a substitute, solely a really compact (salted) hash of those headers is saved (in per-peer reminiscence, discarded upon disconnect).
• In a second section, 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 strategy comes at a price – 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 ample, as we’d like the power 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 are 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 towards it earlier than validation, which might price an attacker hundreds of thousands of tries to succeed towards.