ASMap Dashboard

The ASMap Dashboard is a visual history of every ASmap build published in bitcoin-core/asmap-data, scored against the live Bitcoin network. It is my Summer of Bitcoin 2026 project, mentored by fjahr, with jurraca co-mentoring. The live site runs on GitHub Pages; discussion threads are on bnoc and Delving Bitcoin.

Some background. A Bitcoin Core node keeps only a small number of outbound connections. An attacker who fills all of those slots with machines they control can feed the node a false view of the chain, hide transactions from it, or cut it off entirely. That is an eclipse attack. The defense is to connect to peers in different parts of the internet, so no single party can occupy every slot. Grouping peers by IP prefix does this badly, because a cloud host like AWS owns thousands of prefixes and would still look like thousands of independent peers. ASmap groups every address by the autonomous system that announces it instead, so one operator counts as one group no matter how many addresses it holds. The feature has been in Bitcoin Core since v0.20, and since v31 every release ships with a map embedded.

Each map is a snapshot of internet routing, and routing moves. That leaves two questions that stayed open for years: when has an embedded map aged enough to become a liability, and how do you tell whether a freshly built map is an improvement or a regression before it ships? Both need a continuous measurement of how the maps fit the actual network. That measurement did not exist, so this project builds it.

What it does

The dashboard has two jobs, and everything on it belongs to one of them. The project is under active development and the layout changes as feedback comes in. The jobs underneath are stable.

The first job is evaluating the map history itself. The asmap-data repo has published builds since January 2024, each one produced by kartograf from public routing data and verified in coordinated launches (I wrote up how those work in a separate post).

Dashboard History tab showing cumulative IPv4 drift since the oldest build, light theme — History view for IPv4 over the full series: cumulative drift since the January 2024 build sits near 16%, mostly from prefixes that were reassigned to a different AS. Newly mapped and unmapped space stay low. The numbers are computed on the unfilled map variant, because the fill heuristic that Core embeds would invent churn that never happened in the routing data.

Dashboard History tab showing cumulative IPv4 drift since the oldest build, dark theme — History view for IPv4 over the full series: cumulative drift since the January 2024 build sits near 16%, mostly from prefixes that were reassigned to a different AS. Newly mapped and unmapped space stay low. The numbers are computed on the unfilled map variant, because the fill heuristic that Core embeds would invent churn that never happened in the routing data.

The second job is comparing those maps against the observed network. A map can be internally consistent and still describe an internet that no Bitcoin node lives in, so the dashboard takes node snapshots from real crawls and asks how well each build places them. The ongoing node data comes from the daily bitnod.es exports published by BitMEX Research. From each snapshot it computes concentration and placement metrics: how likely two random nodes are to sit in the same AS, how many operators together host half the network, how many peer-diversity buckets the nodes collapse into once a map is loaded, and how wrong an aging map would be for today’s peers.

Dashboard Network tab scoring the July build against a bitnod.es crawl, light theme — Network view scored against the bitnod.es snapshot from July 20, 2026: 8,964 clearnet peers, of which the map can place 8,958. The HHI of 0.032 means two random nodes have a 3.2% chance of sitting in the same AS, and 17 operators together host half of all mapped nodes. With ASmap loaded, those peers collapse from 4,477 /16-style buckets into 1,277 operator buckets.

Dashboard Network tab scoring the July build against a bitnod.es crawl, dark theme — Network view scored against the bitnod.es snapshot from July 20, 2026: 8,964 clearnet peers, of which the map can place 8,958. The HHI of 0.032 means two random nodes have a 3.2% chance of sitting in the same AS, and 17 operators together host half of all mapped nodes. With ASmap loaded, those peers collapse from 4,477 /16-style buckets into 1,277 operator buckets.

One of those numbers answers the aging question from the top directly: right now about 3.6% of today’s nodes would be filed under the wrong AS by a one-year-old map. That figure comes from scoring old builds against current crawls.

Between the two jobs sits a Diff Explorer. It compares any two builds, classifies every changed prefix, and then translates the prefix churn into the number that matters: how many actually observed nodes end up in a different AS.

Diff Explorer comparing the June and July 2026 builds, light theme — Diff Explorer for June 4 vs July 2, 2026: 89.8% of IPv4 /16 buckets match. On the node side, only 80 of 7,513 observed IPv4 peers change AS. Big prefix churn, small effect on real peers. That asymmetry is easy to miss if you only look at map diffs.

Diff Explorer comparing the June and July 2026 builds, dark theme — Diff Explorer for June 4 vs July 2, 2026: 89.8% of IPv4 /16 buckets match. On the node side, only 80 of 7,513 observed IPv4 peers change AS. Big prefix churn, small effect on real peers. That asymmetry is easy to miss if you only look at map diffs.

In roughly the order I plan to do them, over the remaining weeks of Summer of Bitcoin:

Harden the bitnod.es path with per-node ASN from WHOIS, so the decay curve stands on public data alone
Make fresh snapshots visible near real time instead of on the daily cron
Write the metric documentation: what each number means, its limits, and how to reproduce it locally
A geo view (per-country concentration) once the WHOIS path is stable
Deploy under an asmap.org subdomain

If a number on the dashboard looks wrong from where you sit, I want to hear about it: the fastest way is an issue on the repo.

What it does

Next