mining: add cooldown to createNewBlock() immediately after IBD #34184
Conversation
DrahtBot
changed the title
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34184. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please copy-paste ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Sjors
force-pushed
the
2025/12/cool-down
branch
from
4a0b81d to
a73a5b6
Compare
Sjors
force-pushed
the
2025/12/cool-down
branch
from
a73a5b6 to
62524ac
Compare
At startup isInitialBlockDownload() stops returning true once there’s less than a day of blocks left to sync. Connected mining clients will receive a flood of new templates as these last blocks are connected. Fix this by briefly pausing block template creation while the best header chain is ahead of the tip. If no tip update happens for one second, we stop waiting. It’s not safe to keep waiting, because a malicious miner could announce a header and delay revealing the block, causing all other miners using this software to stall. The cooldown only applies to createNewBlock(), which is typically called once per connected client. Subsequent templates are provided by waitNext(). Fixes bitcoin#33994
Sjors
force-pushed
the
2025/12/cool-down
branch
from
62524ac to
e8b01c4
Compare
|
Switched to avoid mock time for the cooldown mechanism (it's possible, but would require additional refactoring). Added a constraint to ignore alternative header branches. This probably doesn't matter in real life, but it does in tests. E.g. the assume_utxo test "Check importing a snapshot where current chain-tip is not an ancestor of the snapshot block but has less work" creates an alternative chain of blocks despite having better headers (but not their blocks). In real life this implies a giant block witholding attack. |
|
ACK e8b01c4 Tested on macOS - Code review:
Nice fix for #33994 |
|
🐙 This pull request conflicts with the target branch and needs rebase. |
3 participants
At startup
isInitialBlockDownload()stops returning true once there’s less than a day of blocks left to sync. Connected mining clients will receive a flood of new templates as these last blocks are connected.Fix this by briefly pausing block template creation while the best header chain is ahead of the tip. If no tip update happens for one second, we stop waiting.
It's not safe to keep waiting, because a malicious miner could announce a header and delay revealing the block, causing all other miners using this software to stall.
The cooldown only applies to
createNewBlock(), which is typically called once per connected client;waitNext()remains unchanged.Fixes #33994