validation: Move warningcache to ChainstateManager and rename to m_warningcache

[dimitaracev]

Removes warningcache and moves it to ChainstateManager. Also removes the respective TODO completely.

[DrahtBot]

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

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	TheCharlatan, ajtowns, ryanofsky
Concept ACK	dergoegge

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #27596 (assumeutxo (2) by jamesob)

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.

[ajtowns]

Concept ACK

[maflcko]

Please keep you commits squashed according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits Otherwise it is harder to review

[dimitaracev]

@MarcoFalke Thanks for the remainder, squashed them and it should be good now.

[dergoegge]

Concept ACK

[TheCharlatan]

ACK 5526849

[ajtowns]

ACK 5526849

Looking at this, it occurs to me that we're actually being a bit wasteful scanning through ~780k historical headers 29 times (or 2.4M headers 29 times for testnet) every time we startup. Replacing MinBIP9WarningHeight with MinBIP9WarningStartTime (set it to say 2022-07-01 initially), and using it for WarningBitsConditionChecker::BeginTime(), and just bumping it at each release might be worthwhile.

[dimitaracev]

ACK 5526849

Looking at this, it occurs to me that we're actually being a bit wasteful scanning through ~780k historical headers 29 times (or 2.4M headers 29 times for testnet) every time we startup. Replacing MinBIP9WarningHeight with MinBIP9WarningStartTime (set it to say 2022-07-01 initially), and using it for WarningBitsConditionChecker::BeginTime(), and just bumping it at each release might be worthwhile.

Good point, should increase the startup time significantly. I'm on it and will address it in a following PR.

[maflcko]

Please remove the merge commit in this branch. A merge commit will be created by the merge script.

[ajtowns]

Good point, should increase the startup time significantly. I'm on it and will address it in a following PR.

(For the record I don't think this will affect startup time significantly and that you'd need to add bench logging code to even observe the difference outside of the noise of disk reads and reconnecting on the network)

[dimitaracev]

Please remove the merge commit in this branch. A merge commit will be created by the merge script.

Somehow when I synced my forked repo with the latest changes, it merged this branch too. thx

[dimitaracev]

Good point, should increase the startup time significantly. I'm on it and will address it in a following PR.

(For the record I don't think this will affect startup time significantly and that you'd need to add bench logging code to even observe the difference outside of the noise of disk reads and reconnecting on the network)

I just assumed that since there would be less block header processing, but what you say makes sense in that regard.

[ryanofsky]

Code review ACK 5526849

This change does seem ready to merge, but I notice it conflicts with #27596 so might not be worth creating more rebase churn there. Will leave alone for now and wait for more input or a better opportunity to merge

[dimitaracev]

The priority of this change should be pretty low anyways so I agree with that.

[ajtowns]

This change does seem ready to merge, but I notice it conflicts with #27596 so might not be worth creating more rebase churn there. Will leave alone for now and wait for more input or a better opportunity to merge

FWIW, I think the rebase churn is pretty trivial (the PR's change neighbouring lines in validation.h -- this one introduces m_warningcache while assumeutxo moves GetSnapshotBaseHeight), #27596 needs rebase anyway (to combine the fixups at least), and it doesn't conflict with #27746 which I think is the next part of assumevalid, though is still draft.

[fanquake]

I think it's ok to merge this now.