Theoretical v25.0 deployment with ASMap

bitcoin_v25_asmap.md

Theoretical ASMap deployment for v25.0 release

For reference, see the general release schedule of v25.0 here: bitcoin/bitcoin#26549

Tools/Repositories mentioned:

• asmapy
• sipasmap
• kartograf

Steps

1. Between Feature Freeze (2023-04-01) and RC1 tagging (2023-04-14) anyone can open a PR to the asmap-data repo in the Bitcoin Core org (needs to be recreated, demo here). The map can be created with the tool that is most ready and should have rough consensus that it is safe to be used for this purpose: asmapy, sipasmap and kartograf (TBD).
2. Anyone can review the PRs and candidate files using tools, such as asmapy/sipasmap diffing, kartograf coverage report, etc. There should be some documentation at one place listing the tools that are possible to use for reviewing but the emphasis should also be on people exploring different ways and using ankles that are only available to them, i.e. check if their own node IP is mapped to the correct AS and testing the file in their own node for example.
3. By the time rc1 is tagged, maintainers should decide on one candidate file to be used in the release, based on the reviews (that's probably a bit tight, especially when we do this for the first time). The candidate file can still receive review until final is tagged, of course, and it may be swapped for another one if issues are discovered with the chosen file. If the file is swapped it should be included in at least one more rc and that rc should be given at least one more week of testing.
4. As part of the build process the chosen file is pulled from the asmap-data, compressed, and embedded into the binary. The hash of the file should be validated and logged so that users can compare it to the hash of the file they can download from asmap-data and audit.
5. The file is embedded in the v25.0 binary. TBD if asmap should be used as default already with the first version that has an asmap embedded, it should probably be opt-in via a flag as this first step.

What is/are the reason(s) to have the file embedded in the binary?

This is based on the assumption that even a non-ideal or outdated ASMap file is better for peer diversity than just using the current default of /16 prefixes. If using an ASMap file is better than /16s we should strive to make it the default so it may be used by as many users as possible in the network unless they have a specific reason to change this. This makes the network stronger as a whole. In order to make ASMap the default to be used by any user who just downloads the binary and doesn't want to bother with changing configuration, we need to embed a ASMap that can be used as the default since the bucketing logic can not work without that data.

[embedding the binary probably] makes the network stronger as a whole

Thanks. This also explains why there is a wish to synchronize the release cycles of asmap and Bitcoin Core.

What would the size change for release downloads be?

[embedding the binary probably] makes the network stronger as a whole

Thanks. This also explains why there is a wish to synchronize the release cycles of asmap and Bitcoin Core.

What would the size change for release downloads be?

I haven't been so concerned with the compression lately so I don't have the numbers for the latest maps I created but I remember it was between 1 and 2MB the last time I checked.

For completeness adding this here: In a parallel conversation in another gist about the use of diffs to increase trust the candidate file, I made the following statement that might be relevant here:

"Maybe the most likely way of making this work I can see right now is the following: When you want to open a PR as described in Step 1 here then you could tell @brunoerg privately about it and ask him to generate the file at the same time with the same process. You open the PR and then Bruno comments, saying that you both collaborated and what his differences were, and that he thinks the file is good. I personally would still give this file the same scrutiny and I would also discount Bruno's ACK a bit (if he even gives it explicitly), similar to how I would view a PR that would include individual commits from both of you. But this may give you an additional boost from other individual reviewers and maybe over time this turns into a standard as the files that were created in this way get more reviews/ACKs and tend to be used in the binary over those created by only one contributor."