AssumeUTXO: drop background sync? #36557

This zooms in on one aspect of:

• #32377

And has a prerequisite (which itself needs careful consideration):

• #36543

We currently sync from the snapshot to the tip, and then from genesis to the snapshot. My understanding is that there are several reasons for this:

1. Provide additional assurance that the snapshot is legit (we shut down if it's not), i.e. "the trust model is only relaxed for a limited amount of time" #15605
2. Have a fully functional node (complete indexes, unpruned) at the end
3. Handle deep reorgs
4. Maintain (social) pressure to keep ordinary IBD affordable (e.g. #28616 (comment))

It comes with downsides: a. Code complexity (see #32377) b. Large additional download

The benefit of (1) is rather theoretical in my opinion and e.g. #35054 (comment).

Most of (2) can be achieved without validation [^0].

Requiring a full -reindex(chainstate) for (3) doesn't seem unreasonable.

It seems inevitable that users will want to avoid or delay (b), e.g. I proposed it in:

• #31023

And that would defeat (1) and (4).

This is why I think the universal snapshot check[^1] proposed in #36543 is a good idea, and would let us drop the (mandatory) background validation.

Currently the snapshot is only verified by reviewers and those who load the AssumeUTXO snapshot. The latter only find out when the background sync finishes.

With the approach in #36543 everyone verifies the snapshot. If we then drop background validation, everyone except AssumeUTXO users verifies the snapshot. And that group can still verify the software by syncing a fresh node up to the snapshot height.[^2]

[^0]: we have the complete header chain, so can download the blocks with validating them, and generate indexes. Generating undo data might be trickier, which -blockfilterindex and -coinstatsindex need.

[^1]: as I'll comment on that PR, I don't think think a failing check should be considered a consensus failure, but there should be a loud warning.

[^2]: we can make this easier, e.g. using IPC to spawn such a node and monitor it, feeding it our headers, importing its blocks and undo data after completion, etc. All this while avoiding the multiple chainstate abstraction in the software itself. We could compare this approach with the complexity of the existing dual chainstate approach (after bug fixes).

Thanks for writing this up, Sjors. Concept ACK on dropping mandatory background validation, conditional on #36543 landing first. Some thoughts on each of the points:

(1) Additional assurance

With the universal snapshot check from #36543, every node verifies the AssumeUTXO commitment during IBD, not only those who load a snapshot. That already covers most of what background sync provides today, and users who want the full guarantee can still sync a fresh node up to the snapshot height (footnote 3). One thing I'd suggest: the "trust is only relaxed for a limited amount of time" property is documented in #15605. If we drop background validation, the docs and release notes should explicitly describe the new trust model, so users know what they are relying on.

(2) Complete indexes

I agree that block download plus index building can be separated from validation. My understanding of footnote 1 is that blockfilterindex and coinstatsindex are the tricky ones because they need undo data. Is the plan to connect the historical blocks to a UTXO set built from genesis, without script verification, just to produce undo data? Or is there a cheaper way? It would be good to know what the cost of that path is compared to today's background sync.

(3) Deep reorgs

Requiring -reindex-chainstate for a reorg deeper than the snapshot height seems reasonable to me, as such a reorg is extremely unlikely. I'd suggest the node prints a clear, actionable error in that case, rather than a generic failure.

(4) Keeping IBD affordable

This is the one I find hardest to weigh, since it is a social incentive rather than a technical one. If background sync is dropped, nothing technical keeps ordinary IBD "in view" for developers. I don't think that alone is a reason to keep a mandatory 2x sync. But maybe it can be preserved in a lighter way, e.g. keeping background validation as an opt-in option (rather than removing the code immediately), so that it remains tested.

On -pausebackgroundsync (#31023)

I agree this is a strong argument. If users will predictably want to pause or delay the download, then the mandatory behavior mostly gives a false sense of guarantee, as it defeats (1) and (4) anyway.

On #36543 and failure behavior

I agree with your footnote 2 that a failing check should not be a consensus failure. A question though: what should happen to a node that already loaded a snapshot which later turns out to be wrong? A loud warning is good, but I think there should also be clear recovery guidance (e.g. wipe the snapshot chainstate and resync), so that users are not left running on a bad chainstate.

On footnote 3 (IPC)

Spawning a separate node via IPC, feeding it our headers and importing its blocks and undo data afterwards, sounds attractive because it avoids the multiple-chainstate abstraction in the main code. It would be useful to compare its complexity against the existing dual-chainstate approach after the known bug fixes, as you mention.

Possible path forward

1. Land #36543 (universal snapshot check, warning instead of consensus failure).
2. Make background validation non-default/opt-in for at least one release cycle.
3. Provide the index-building path without full validation.
4. Remove the dual-chainstate code once the above is proven.

Happy to help test or review #36543 if that is useful.

۰من مبتدی بودم ببخشید

در تاریخ شنبه ۱۷ اکتبر ۲۰۲۶، ۱۴:۱۱ Tarhadi @.***> نوشت:

Tarhadi97 left a comment (bitcoin/bitcoin#36557) https://github.com/bitcoin/bitcoin/issues/36557#issuecomment-6232806127

Thanks for writing this up, Sjors. Concept ACK on dropping mandatory background validation, conditional on #36543 https://github.com/bitcoin/bitcoin/pull/36543 landing first. Some thoughts on each of the points:

(1) Additional assurance

With the universal snapshot check from #36543 https://github.com/bitcoin/bitcoin/pull/36543, every node verifies the AssumeUTXO commitment during IBD, not only those who load a snapshot. That already covers most of what background sync provides today, and users who want the full guarantee can still sync a fresh node up to the snapshot height (footnote 3). One thing I'd suggest: the "trust is only relaxed for a limited amount of time" property is documented in #15605 https://github.com/bitcoin/bitcoin/issues/15605. If we drop background validation, the docs and release notes should explicitly describe the new trust model, so users know what they are relying on.

(2) Complete indexes

I agree that block download plus index building can be separated from validation. My understanding of footnote 1 is that blockfilterindex and coinstatsindex are the tricky ones because they need undo data. Is the plan to connect the historical blocks to a UTXO set built from genesis, without script verification, just to produce undo data? Or is there a cheaper way? It would be good to know what the cost of that path is compared to today's background sync.

(3) Deep reorgs

Requiring -reindex-chainstate for a reorg deeper than the snapshot height seems reasonable to me, as such a reorg is extremely unlikely. I'd suggest the node prints a clear, actionable error in that case, rather than a generic failure.

(4) Keeping IBD affordable

This is the one I find hardest to weigh, since it is a social incentive rather than a technical one. If background sync is dropped, nothing technical keeps ordinary IBD "in view" for developers. I don't think that alone is a reason to keep a mandatory 2x sync. But maybe it can be preserved in a lighter way, e.g. keeping background validation as an opt-in option (rather than removing the code immediately), so that it remains tested.

On -pausebackgroundsync (#31023 https://github.com/bitcoin/bitcoin/pull/31023)

I agree this is a strong argument. If users will predictably want to pause or delay the download, then the mandatory behavior mostly gives a false sense of guarantee, as it defeats (1) and (4) anyway.

On #36543 https://github.com/bitcoin/bitcoin/pull/36543 and failure behavior

I agree with your footnote 2 that a failing check should not be a consensus failure. A question though: what should happen to a node that already loaded a snapshot which later turns out to be wrong? A loud warning is good, but I think there should also be clear recovery guidance (e.g. wipe the snapshot chainstate and resync), so that users are not left running on a bad chainstate.

On footnote 3 (IPC)

Spawning a separate node via IPC, feeding it our headers and importing its blocks and undo data afterwards, sounds attractive because it avoids the multiple-chainstate abstraction in the main code. It would be useful to compare its complexity against the existing dual-chainstate approach after the known bug fixes, as you mention.

Possible path forward

1. Land #36543 https://github.com/bitcoin/bitcoin/pull/36543 (universal snapshot check, warning instead of consensus failure).
2. Make background validation non-default/opt-in for at least one release cycle.
3. Provide the index-building path without full validation.
4. Remove the dual-chainstate code once the above is proven.

Happy to help test or review #36543 https://github.com/bitcoin/bitcoin/pull/36543 if that is useful.

— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/36557?email_source=notifications&email_token=BWNRS2UOLU6FH2Q4YZB2ELD5UNEEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMRTGI4DANRRGI32M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-6232806127, or unsubscribe https://github.com/notifications/unsubscribe-auth/BWNRS2WIG4PVX4ZHDQ73UXT5UNEEDAVCNFSNUABDKJSXA33TNF2G64TZHMYTCOBRHEZDOO2JONZXKZJ3GU4DSNBTGM4DIOJYUF3AE . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/BWNRS2XSSV2BQT7F5YDNO3D5UNEEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMRTGI4DANRRGI32M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ and Android https://github.com/notifications/mobile/android/BWNRS2TDBYFDQQ5AQZ4ERBL5UNEEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMRTGI4DANRRGI32M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ. Download it today! You are receiving this because you are subscribed to this thread.Message ID: @.***>

I am in favor of removing AssumeUTXO background validation completely, for the following reasons:

• Background validation removes the need to trust the loaded snapshot, but only eventually: the node is usable right away under an extra trust assumption, which is lifted once validation completes. This two-phase trust model is harder to communicate and reason about. The promise may be interpreted as the misleading understanding that the hash doesn't really need to be trusted. Without background validation the assumption is simply: trust the snapshot hash shipped in the binary. Note that the trust can be based on reported checks from trusted individuals and the collective reputation of the project developers. The proposed #36543 would increase the trust by having a large number of other nodes check the correctness of the hash.

• AssumeUTXO is especially attractive to users with limited resources (low-end hardware, limited disk, limited memory, slow or metered internet). With mandatory background validation, though, they save nothing in total. Bandwidth and CPU are the same as IBD plus the snapshot download, and disk use is temporarily higher because of two chainstates. Users with a limited network connection see no real benefit from AssumeUTXO with mandatory background validation.

• There is an alternative for users who want to "upgrade" their trust assumption without background validation: they can skip AssumeUTXO and perform a regular IBD. This way they perform full validation, at the cost of the node being unusable during IBD. Note that pruning and "assumevalid" are options available for low-resource use cases.

• An important concern is the code complexity of background validation, resulting from the need to support multiple simultaneous chainstates. This is a potential source of errors and security issues (the issue #32377 lists several such issues). Removing the background validation requirement would reduce technical debt (which is an important meta-goal of the project).

Note that optional background validation would allow some users to validate, but it would not enable the mentioned technical debt reduction. It's a the worst of both worlds, but may be appropriate as a temporary solution for one release cycle (though I advocate against it).

A minor clarification on the "everyone" in "With the approach in #36543 everyone verifies the snapshot.": More precisely "everyone who performs IBD and runs the same version (has the same code-included latest snapshot)". This clarification does not affect the original arguments.