You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
3add234 ui: show header pre-synchronization progress (Pieter Wuille)
738421c Emit NotifyHeaderTip signals for pre-synchronization progress (Pieter Wuille)
376086f Make validation interface capable of signalling header presync (Pieter Wuille)
93eae27 Test large reorgs with headerssync logic (Suhas Daftuar)
3555473 Track headers presync progress and log it (Pieter Wuille)
03712dd Expose HeadersSyncState::m_current_height in getpeerinfo() (Suhas Daftuar)
150a548 Test headers sync using minchainwork threshold (Suhas Daftuar)
0b6aa82 Add unit test for HeadersSyncState (Suhas Daftuar)
83c6a0c Reduce spurious messages during headers sync (Suhas Daftuar)
ed6cddd Require callers of AcceptBlockHeader() to perform anti-dos checks (Suhas Daftuar)
551a8d9 Utilize anti-DoS headers download strategy (Suhas Daftuar)
ed47094 Add functions to construct locators without CChain (Pieter Wuille)
84852bb Add bitdeque, an std::deque<bool> analogue that does bit packing. (Pieter Wuille)
1d4cfa4 Add function to validate difficulty changes (Suhas Daftuar)
Pull request description:
New nodes starting up for the first time lack protection against DoS from low-difficulty headers. While checkpoints serve as our protection against headers that fork from the main chain below the known checkpointed values, this protection only applies to nodes that have been able to download the honest chain to the checkpointed heights.
We can protect all nodes from DoS from low-difficulty headers by adopting a different strategy: before we commit to storing a header in permanent storage, first verify that the header is part of a chain that has sufficiently high work (either `nMinimumChainWork`, or something comparable to our tip). This means that we will download headers from a given peer twice: once to verify the work on the chain, and a second time when permanently storing the headers.
The p2p protocol doesn't provide an easy way for us to ensure that we receive the same headers during the second download of peer's headers chain. To ensure that a peer doesn't (say) give us the main chain in phase 1 to trick us into permanently storing an alternate, low-work chain in phase 2, we store commitments to the headers during our first download, which we validate in the second download.
Some parameters must be chosen for commitment size/frequency in phase 1, and validation of commitments in phase 2. In this PR, those parameters are chosen to both (a) minimize the per-peer memory usage that an attacker could utilize, and (b) bound the expected amount of permanent memory that an attacker could get us to use to be well-below the memory growth that we'd get from the honest chain (where we expect 1 new block header every 10 minutes).
After this PR, we should be able to remove checkpoints from our code, which is a nice philosophical change for us to make as well, as there has been confusion over the years about the role checkpoints play in Bitcoin's consensus algorithm.
Thanks to Pieter Wuille for collaborating on this design.
ACKs for top commit:
Sjors:
re-tACK 3add234
mzumsande:
re-ACK 3add234
sipa:
re-ACK 3add234
glozow:
ACK 3add234
Tree-SHA512: e7789d65f62f72141b8899eb4a2fb3d0621278394d2d7adaa004675250118f89a4e4cb42777fe56649d744ec445ad95141e10f6def65f0a58b7b35b2e654a875
0 commit comments