Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Thursday, January 9, 2025

bitcoin core – How does headers-first stop disk-fill assault?

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.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles