Skip to content

Conversation

@stringintech
Copy link
Contributor

@stringintech stringintech commented Oct 12, 2025

Currently, after assumeutxo background validation finishes, the node continues to skip peers that don't have the snapshot block in their best chain until restart. This unnecessarily excludes peers from block downloads even though the background sync has completed and undo data is available.

The restriction persists because m_chainman.CurrentChainstate().SnapshotBase() continues to return the snapshot base block until restart, even after validation completes. Added m_chainman.CurrentChainstate().m_assumeutxo == Assumeutxo::UNVALIDATED check to only apply the peer restriction while background validation is ongoing.

Also added test coverage in feature_assumeutxo.py that verifies peers without the snapshot block can be used for block downloads after background validation completes. The test fails without this fix.

@DrahtBot DrahtBot added the P2P label Oct 12, 2025
@DrahtBot
Copy link
Contributor

DrahtBot commented Oct 12, 2025

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33604.

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK fjahr
Concept ACK sedited, Raimo33, mzumsande
Stale ACK stratospher

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

Conflicts

No conflicts as of last run.

@sedited
Copy link
Contributor

sedited commented Oct 12, 2025

Nice, Concept ACK.

@fanquake
Copy link
Member

cc @mzumsande

@stringintech
Copy link
Contributor Author

This change allows the snapshot chainstate to reorg to chains that don't include the snapshot block after validation completes (not sure yet if this is the only mechanism that would allow such reorgs), so we must not assume anywhere in the codebase that SnapshotBase() is always an ancestor of the active tip. I'll take a closer look to see if any such assumptions exist, but I thought this was worth noting here.

@Raimo33
Copy link
Contributor

Raimo33 commented Oct 14, 2025

Concept ACK

approach seems fine

Copy link
Contributor

@stratospher stratospher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 9f946a7.

nice! I think this aligns with the original intention to restrict the peer only when background sync isn't over in #29519 (comment) where this code was introduced.

looks like we might incorrectly set pindexLastCommonBlock in L1401 to the previous best known block tip again in this scenario. but it's not a problem since we immediately reset it back to the correct value + comments suggest it's ok to set it incorrectly and that's way better than introducing more conditions.

also slightly related: #30288

@DrahtBot DrahtBot requested a review from sedited October 14, 2025 18:22
@stringintech
Copy link
Contributor Author

Thanks for the links @stratospher!
FYI, calculating pindexLastCommonBlock is undergoing some improvements in #32180, and I will probably have to rebase onto that change. But either way, as you mentioned, it shouldn't cause any issues.

Copy link
Contributor

@mzumsande mzumsande left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

@fjahr
Copy link
Contributor

fjahr commented Dec 17, 2025

Concept ACK

@stringintech stringintech force-pushed the 2025/10/assumeutxo-sync-after-validation branch from 9f946a7 to 6b92a69 Compare December 18, 2025 08:57
@stringintech
Copy link
Contributor Author

stringintech commented Dec 18, 2025

9f946a7 to 5cd0968 (compare) - rebased, resolved conflict with #30214, and addressed #33604 (comment). Also PR and first commit descriptions are updated.

edit: second force push (6b92a69 to 5cd0968) is to drop an accidentally included iostream header.

…sumeutxo validation

After assumeutxo background validation completes, allow block downloads from peers that don't have the snapshot block in their best chain.

Previously, these peers were skipped until restart because `m_chainman.CurrentChainstate().SnapshotBase()` continued returning non-null even after validation finished. Add `m_chainman.CurrentChainstate().m_assumeutxo == Assumeutxo::UNVALIDATED` check to only apply the restriction while background validation is ongoing.
Add test coverage to ensure peers without the snapshot block in their chain can be used for block downloads after background validation completes. The test fails without the fix in the previous commit.
@stringintech stringintech force-pushed the 2025/10/assumeutxo-sync-after-validation branch from 6b92a69 to 5cd0968 Compare December 18, 2025 09:11
Copy link
Contributor

@fjahr fjahr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tACK 5cd0968

Reviewed code and confirmed the new test failed previous to the behavior change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants