Add headerssync tuning parameters optimization script to repo

[sipa]

Builds upon #25946, as it incorporates changes based on the selected values there.

This adds the headerssync tuning parameters optimization script from https://gist.github.com/sipa/016ae445c132cdf65a2791534dfb7ae1 to the repository, updates the parameters based on its output, and adds release process instructions for doing this update in the future.

A few considerations:

• It would be a bit cleaner to have these parameters be part of CChainParams, but due to the nature of the approach, it really only applies to chains with unforgeable proof-of-work, which we really can only reasonably expect from mainnet, so I think it's fine to keep them local to headerssync.cpp. Keeping them as compile-time evaluatable constants also has a (likely negligible) performance impact (avoiding runtime modulo operations).
• If we want to make sure the chainparams and headerssync params don't go out of date, it could be possible to run the script in CI, and and possibly even have the parameters be generated automatically at build time. I think that's overkill for how unfrequently these need to change, and running the script has non-trivial cost (~minutes in the normal python interpreter).
• A viable alternative is just leaving this out-of-repo entirely, and just do ad-hoc updating from time to time. Having it in the repo and release notes does make sure it's not forgotten, though adds a cost to contributors/maintainers who follow the process.

[Sjors]

Concept ACK

[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	ajtowns
Concept ACK	Sjors, dergoegge, sdaftuar

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

Conflicts

No conflicts as of last run.

[sipa]

This shows worst-case per-peer memory usage for headers synchronization, assuming the parameters are regularly updated (3 years beforehand), or never updated past this PR (assuming growth at 600 seconds per block, and minchainwork lagging behind a constant time).

[Sjors]

@sipa why does the chart start three years in the future? In case you remake it (not really necessary), can you extrapolate to 2106? (users will have to download some sort of update before then anyway, so it's a natural ending point for the green line)

[sipa]

@Sjors This graph is showing the result of showing effect of, and optionally optimizing for, a state 3 years in the future. When I'm back from travel next week I'll redo the graphs in a more intuitive way.

[dergoegge]

Concept ACK on having this in the repo.

I have partially reviewed previous versions of this script and will fully review the current version soon.

[ajtowns]

ACK edfcb52

[ajtowns]

The script now suggests 608 and 14487 (TIME=2026/11/15, MCWH=809261)

(Bumping TIME by six months seems to have a much bigger impact than bumping MCWH by 26k blocks; but if we're going to optimise things, seems silly to do anything other than optimise for the actual value of MCWH)

[sipa]

I've rebased the PR, and updated the numbers to roughly match the code currently in the repository (with dates/chainwork corresponding to the 25.0 release). Updating for 26.0 would be done when updating the chainparams for 26.

[ajtowns]

@Sjors This graph is showing the result of showing effect of, and optionally optimizing for, a state 3 years in the future. When I'm back from travel next week I'll redo the graphs in a more intuitive way.

Perhaps plot the the two lines based on:

• using the proposed parameters in this PR indefinitely (ie, showing how badly the security against a worst case low work attacker degrades over time)
• bumping the parameters every six months, with time being bumped by 182.5 days and chainwork headers increasing by 26280 (ie, what you get if you upgrade to the latest release whenever it comes out)
• (maybe add another line, that tracks performance if you're constantly 1/2/3 years behind the current release?)

[sipa]

@ajtowns Working on new graphs.

[sipa]

This shows the worst-case memory over time (maximum of normal sync memory usage and timewarp attack scenario), for 6 different configurations (created 50 weeks apart) with the minchainwork_headers value set at the time of configuration, and the time value set 3 years later than the configuration time.

[ajtowns]

So the 2023-05 params which are set to work well until 2026-05, continue working better than the 2024-04 params until about 2026-10; by 2027-05 they're performing perhaps ~15kB (?) worse than the 2024-05 params. Interesting that for the normal lifetime of a release (eg 2024-05 through 2024-11) that release will use ~20kB more memory than earlier releases that are still supported, due to the bump in bufsize. Seems fine to me

[ajtowns]

reACK 3d420d8

[sdaftuar]

ACK.

I didn't figure out exactly what's going on in the optimize function, but I did verify that my dumb brute force search using the functions I did understand (find_bufsize and memory_usage) produced the same results, so that seems pretty good to me.

[Sjors]

Also the script needs +x