Update embedded asmap to 1770307200 for v31 #34696

1. 
   fjahr commented at 10:28 pm on February 27, 2026: contributor

   This updates the currently embedded data ahead of the v31 release.

   It currently uses the map from the 1770307200 run

   • Pull request: https://github.com/bitcoin-core/asmap-data/pull/43
   • Issue: https://github.com/bitcoin-core/asmap-data/issues/42

   Using this data would be find but we may want to wait and use the data from the upcoming run planned on March 5th: https://github.com/bitcoin-core/asmap-data/issues/44 or there could even be a dedicated run planned for the release. Each of these options would be fine but I thought it would be better to open the PR now laying out the options since per the release schedule this task should be done by May 10th and if we wait for the May 5th run the PR would only be opened in the very last minute. And if that run fails we may have to fall back to this data anyway.

2. Update embedded asmap to 1770307200 641617c090
3. 
   DrahtBot commented at 10:28 pm on February 27, 2026: contributor

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

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

4. 
   achow101 commented at 10:36 pm on February 27, 2026: member

   Branching is scheduled for March 10th, so I’d prefer to update it with the March 5th run.
5. achow101 added this to the milestone 31.0 on Feb 27, 2026
6. DrahtBot added the label CI failed on Feb 27, 2026
7. DrahtBot removed the label CI failed on Mar 2, 2026
8. 
   fanquake commented at 11:06 am on March 3, 2026: member

   Yea I think using the March 5th run is fine. I assume this time we’ll be using the new processes where those generating the data will be signing over the outputs, we are saving the raw data somewhere, etc?
9. fanquake marked this as a draft on Mar 3, 2026
10. 
    jurraca commented at 12:08 pm on March 8, 2026: contributor

    @achow101 @fanquake looking to confirm a few things about attestations. The ASmap flow is currently: Generate ASmap with kartograf -> use the one with the most matches -> encode it via contrib/asmap/asmap-tool.py -> open PR to bitcoin-core/asmap-data -> people reproduce the hashes for the encoded files (filled and unfilled) -> merge PR to bitcoin-core/asmap-data

    Does it make sense to have only the people with the “winning hash” attest to their output file hash, and its encoded variants? So if 6 people have a matching hash, they become the subset of participants that must submit attestations.

    Other users could validate that the encoded ASmap included in bitcoin-core/asmap-data has the expected / attested hash, and could decode the ASmap to get the initial file hash too.

    Or is it enough to attest on the hashes of the ASmap with the most matches in a collaborative run’s output? As in, we add the “winning” ASmap to the bitcoin-core/asmap-data and anyone can drive by, recreate the encoded files from the uploaded file, and attest to them.

11. 
    achow101 commented at 1:23 am on March 9, 2026: member

    I am ok with allowing anyone to attest to the asmap files so long as they are reproducible from easily examinable files. In choosing which result is the canonical asmap for that run, other runners can still validate that the encoded files are correctly encoded. They can further look at the diff between their own result and the canonical result to see what differences there are and if those differences are okay. Ultimately, the canonical result can be inspected by anyone and they should be able to attest to that result should its contents be satisfactory to them.

Contributors
fjahr DrahtBot achow101 fanquake jurraca

Milestone
31.0