Add -pausebackgroundsync startup option #31023

When a UTXO snapshot is loaded, this option lets the user pause the verification of historical blocks in the background.

Manual testing is easiest using the signet snapshot, because it loads and reaches the tip quickly (compared to mainnet and testnet3), but not so fast that you don't have to time to call any RPC commands (like testnet4).

magnet:?xt=urn:btih:5e4c8128887dad27b01d74bed9b83dbdc24d74cf&dn=utxo-signet-160000.dat&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

TODO:

• add test

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage

For detailed information about the code coverage, see the test coverage report.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #30666 (validation: fix m_best_header tracking and BLOCK_FAILED_CHILD assignment by mzumsande)

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.

It might make sense to change this into an RPC method. E.g. someone may want to run the background sync only when their laptop is plugged in and on wifi.

The current implementation simply sets BackgroundSyncInProgress() to false, which prevents net_processing from adding background blocks to the download queue.

A more thorough approach would also allocate all of -dbcache to the tip, and perhaps some other things.

Is there a strong use case for this? I'm hesitant to add any more AssumeUTXO complexity than there already is. When a user is on battery / limited bandwidth, they can just shut down Bitcoin Core until they're ready to use it again?

@stickies-v the reason I opened it was because someone needed an easier way to benchmark IBD without going all the way from genesis.

In general this is useful if you don't want to download and process things before the snapshot. Whether that's wise is a different question.

the reason I opened it was because someone needed an easier way to benchmark IBD without going all the way from genesis.

Wait, how does pausing IDB help with benchmarking IBD?

In general this is useful if you don't want to download and process things before the snapshot

Right, I can see the use case for that, but that discussion feels more about disabling rather than pausing background validation. Adding a third option seems unnecessarily confusing?

disabling rather than pausing background validation

I think it's good to maintain the option to finish background validation. E.g. maybe because you want to enable an index.

Wait, how does pausing IDB help with benchmarking IBD?

I had a chat with @Sjors recently regarding a benchmarking use case I have, where I want to benchmark doing IBD on more recent blocks to test flush behaviour. AssumeUTXO seemed useful here in that I can start from, e.g., 800,000 and sync to tip. For this, background validation would likely interfere with the results so having a -pausebackgroundvalidation option seemed useful. Worth mentioning, this is not meant to be a representative benchmark, but rather a way to iterate quickly and see how different DB configurations would have an effect on representative data.

Is there a strong use case for this?

For my use case, all I need is a patch to cherry-pick onto my branches. @Sjors mentioned he had other reasons that this might be generally useful for AssumeUTXO users, hence the PR. Assuming my benchmarking idea works, I could see this being a generally useful option, e.g., for running a regression test where we benchmark IBD performance from 50k blocks back to chaintip nightly (or something like that), so I don't think adding it as an option is a negative. Alternatively, my suggestion for the regression testing / benchmarking use case would be to make it a compile time flag. I haven't checked if we have a notion of "hidden options" (similar to how we have hidden RPCs), but if there is a strong case for making it a runtime flag, I'd suggest hiding it since the use case I envision is more for testing / debugging and not general use.

Thanks for explaining the intended use cases in more detail.

Benchmarking from a fixed height seems useful but also seems quite feasible without -pausebackgroundsync too (e.g. from an existing datadir which allows starting from any height instead of the hardcoded 840.000 blocks)? Worsening the code for test-only purposes is something I think we should only do if the alternatives are too much of a hassle.

Similarly, I don't see a proper use case for end users either. I think the discussion to allow the user to skip background validation entirely (or, have it be a separate process using kernel, allowing the user to (re-)run it whenever they want) I think is valid, but -pausebackgroundsync seems like the wrong way to go to me, so I'm Concept NACK.

but -pausebackgroundsync seems like the wrong way to go to me

What other approach do you have in mind?

What other approach do you have in mind?

Perhaps enumerating the problem(s) you're trying to solve would be a better starting point?

As I've outlined before already:

• I think benchmarking can be solved in other ways, e.g. from pre-created datadirs, or by running a fork with ~this diff applied
• user wants to avoid draining his battery / internet: ctrl+c until he's able to resume, like he would with a regular IBD
• user doesn't want to do background validation at all: like I said earlier:

I think the discussion to allow the user to skip background validation entirely (or, have it be a separate process using kernel, allowing the user to (re-)run it whenever they want) I think is valid...

The main use case I have in mind is some who doesn't want to do background validation. The best reason for that is to save bandwidth, since storage can be saved by pruning just as well. They may later decide to perform this validation.

This PR enables that now in a fairly trivial way: it just doesn't download the blocks. Using process separation and the kernel is not something we can do in the near future. It also seems more complicated than the approach here.

user wants to avoid draining his battery / internet: ctrl+c until he's able to resume, like he would with a regular IBD

That defeats the purpose of assumeutxo: to be able to use the node, mempool and wallet without having to download the entire chain. They only need to keep the tip synced.

I tend to agree with #31023 (comment). Adding a test-only option in this way won't be useful to benchmark previous releases (and compare them), and seems more work than just using a test-only datadir dump.

The main use case I have in mind is some who doesn't want to do background validation.

There are reasons to do the background validation, see #28616 (comment) . If you are adding a foot-gun, at least it should be documented as such, not advertised to users via the release notes and a non-hidden setting.

I agree with the other commentors here. I don't think we should be trying to extend/re-use a user-facing feature for development purposes, especially given the existence of more accurate/repeatable ways of achieving the same thing. Adding this option for the other uses-cases described just further murkies the function of/complicates this feature.

Going to close this for now, given the feedback.