-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for the pruning proof rebuild issue (issue #444) #449
Fix for the pruning proof rebuild issue (issue #444) #449
Conversation
…al data is pruned
…ing point anticone of a newly synced node)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed the last 3 commits.
My knowledge of the pruning system is not deep enough to bring a valuable review on this part of the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fix is mainly the change in header_processor
. There are 3 other sections unrelated to the pruning proof bug. Approving for these sections
- pruning proof bug fix
- kip9 change
- enable-mainnet-mining change
Please address Tiram's comments for the UTXO tracking section.
…t#449) * add a strict assertion which should catch the pruning bug before actual data is pruned * possible fix: add `block_at_depth_2m` as an additional traversal root * rollback: rollback the previous fix since it's not the root cause * add additional dbg info to assertion * bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node) * enable mainnet mining by default * simplify kip 9 beta condition + more mass tests * set default tracked addresses to 1M * fix tracker prealloc property + adds compile time assertion for upper bound
…t#449) * add a strict assertion which should catch the pruning bug before actual data is pruned * possible fix: add `block_at_depth_2m` as an additional traversal root * rollback: rollback the previous fix since it's not the root cause * add additional dbg info to assertion * bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node) * enable mainnet mining by default * simplify kip 9 beta condition + more mass tests * set default tracked addresses to 1M * fix tracker prealloc property + adds compile time assertion for upper bound
…t#449) * add a strict assertion which should catch the pruning bug before actual data is pruned * possible fix: add `block_at_depth_2m` as an additional traversal root * rollback: rollback the previous fix since it's not the root cause * add additional dbg info to assertion * bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node) * enable mainnet mining by default * simplify kip 9 beta condition + more mass tests * set default tracked addresses to 1M * fix tracker prealloc property + adds compile time assertion for upper bound
…t#449) * add a strict assertion which should catch the pruning bug before actual data is pruned * possible fix: add `block_at_depth_2m` as an additional traversal root * rollback: rollback the previous fix since it's not the root cause * add additional dbg info to assertion * bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node) * enable mainnet mining by default * simplify kip 9 beta condition + more mass tests * set default tracked addresses to 1M * fix tracker prealloc property + adds compile time assertion for upper bound
The following describes the pruning bug and the fix assuming sufficient prior knowledge.
Some notation:
The bug is mostly in the case of intermediate levels. It requires that such a block is mined in the anticone of the pruning point (so the bug is likely to occur ~once in a few days, and requires that someone synced a new node exactly at that day).
The logic missing: we did not update relations per level for the pruning point anticone (aka "trusted" blocks).
Scenario: a "lucky" intermediate-level block
R
happened to be in the pruning point anticone. A future blockB
on that level is likely to haveR
as its only parent (for that level). Since level relations are not updated forR
,B
computes Ghostdag for that level overORIGIN
-- essentially starting from blue score 0 instead of building over the previous 2000 blocks. When building the new proof, this segment of blocks (S
=B
+ its future) is topologically disconnected from blockN
which is the block at depth 1000 of the next level (which is likely below the current new pruning point). SoN
becomesroot
, and the traversal starting from it never reachesS
. Leading to a possible prune of blocks inS
(some may be preserved via other levels)Result: following the prune, the proof rebuild fails bcs of blocks missing from
S
. This is only a symptom of the bug, the real problem is that the level proof is literally incomplete.Fix: update relations per level also for trusted blocks