From 7a885518d57c6eb818ebef5fd04a575f324ee8b2 Mon Sep 17 00:00:00 2001 From: Martin Zumsande Date: Fri, 14 Jun 2024 11:29:03 -0400 Subject: [PATCH] p2p: Restrict downloading of blocks for snapshot chain If the best chain of the peer doesn't include the snapshot block, it is futile to download blocks from this chain, because we couldn't reorg to it. We'd also crash trying to reorg because this scenario is not handled. --- src/net_processing.cpp | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/net_processing.cpp b/src/net_processing.cpp index 5c3ec5f7006..2c91b5cf0f5 100644 --- a/src/net_processing.cpp +++ b/src/net_processing.cpp @@ -1397,6 +1397,15 @@ void PeerManagerImpl::FindNextBlocksToDownload(const Peer& peer, unsigned int co return; } + // When we sync with AssumeUtxo and discover the snapshot is not in the peer's best chain, abort: + // We can't reorg to this chain due to missing undo data until the background sync has finished, + // so downloading blocks from it would be futile. + const CBlockIndex* snap_base{m_chainman.GetSnapshotBaseBlock()}; + if (snap_base && state->pindexBestKnownBlock->GetAncestor(snap_base->nHeight) != snap_base) { + LogDebug(BCLog::NET, "Not downloading blocks from peer=%d, which doesn't have the snapshot block in its best chain.\n", peer.m_id); + return; + } + if (state->pindexLastCommonBlock == nullptr) { // Bootstrap quickly by guessing a parent of our best tip is the forking point. // Guessing wrong in either direction is not a problem.