glozow 3d0fca1288
Merge bitcoin/bitcoin#26355: p2p: Handle IsContinuationOfLowWorkHeadersSync return value correctly when new headers sync is started
7ad15d11005eac36421398530da127333d87ea80 [net processing] Handle IsContinuationOfLowWorkHeadersSync return value correctly when new headers sync is started (dergoegge)

Pull request description:

  This PR fixes a bug in the headers sync logic that enables submitting headers to a nodes block index that don't lead to a chain that surpasses our DoS limit.

  The issue is that we ignore the return value on [the first `IsContinuationOfLowWorkHeadersSync` call after a new headers sync is started](fabc031048/src/net_processing.cpp (L2553-L2568)), which leads to us passing headers to [`ProcessNewBlockHeaders`](fabc031048/src/net_processing.cpp (L2856)) when that initial `IsContinuationOfLowWorkHeadersSync` call returns `false`. One easy way (maybe the only?) to trigger this is by sending 2000 headers where the last header has a different `nBits` value than the prior headers (which fails the pre-sync logic [here](fabc031048/src/headerssync.cpp (L189))). Those 2000 headers will be passed to `ProcessNewBlockHeaders`.

  I haven't included a test here so far because we can't test this without changing the default value for `CRegTestParams::consensus.fPowAllowMinDifficultyBlocks` or doing some more involved refactoring.

ACKs for top commit:
  sipa:
    ACK 7ad15d11005eac36421398530da127333d87ea80
  glozow:
    ACK 7ad15d1100

Tree-SHA512: 9aabb8bf3700401e79863d0accda0befd2a83c4d469a53f97d827e51139e2f826aee08cdfbc8866b311b153f61fdac9b7aa515fcfa2a21c5e2812c2bf3c03664
2022-10-24 15:38:37 +01:00
..
2022-09-23 10:48:47 +01:00
2022-10-10 15:44:02 +01:00
2022-04-20 14:29:29 +01:00
2022-07-20 15:34:36 +02:00
2021-12-30 19:36:57 +02:00
2022-08-04 11:32:25 +02:00
2022-08-04 11:32:25 +02:00
2022-07-26 11:05:04 +02:00
2021-12-30 19:36:57 +02:00
2021-12-30 19:36:57 +02:00
2022-08-20 09:33:01 +02:00
2022-08-05 14:59:15 +02:00
2022-08-05 14:59:15 +02:00