*This is a copy of my Summer of Bitcoin midterm report from June 27, 2026. The original is on the Summer of Bitcoin blog.*
When people talk about Bitcoin security they almost always picture mining. Hash rate, energy, warehouses full of machines. The part that quietly keeps the network honest gets far less attention. Every node decides who it connects to and those choices are a real line of defense. Who each node connects to gets far less attention, even though those choices are how it keeps itself from being eclipsed.
A node keeps only a small number of outbound connections. If someone can fill mostall of those slots with machines they control, they can feed that node a false view of the chain, hide transactions from it, or cut it off from the rest of the network. This is the idea behind an eclipse attack and the defense is easy to state. Connect to peers that sit in genuinely different parts of the internet.
Spreading them out is harder than it sounds. The straightforward approach groups peers by their IP prefix, but a singlecloud host like AWS, or a large providerISP, can own thousands of prefixes and still look like many separate peers. ASmap fixes that. It groups every address by the autonomous system that actually owns it, so one provider counts as one group no matter how many addresses it holds. Since v31 it ships with Bitcoin Core. The feature has been in Bitcoin Core since 20.0. Since 31.0 every release ships with a map embedded.
Here is the part that pulled me in. ASmap has been worked on for years, yet onetwo basicquestions question stayed open. Once a map is shipped inside a release, when has it aged enoughso tomuch bethat worthit replacingbecomes a liability? And when a new map is built, how do you tell whether it is an improvement or a regression?
I am Joris, a student and contributor in Summer of Bitcoin 2026, mentored by fjahr and jurraca. My project turns thatthose openquestions question into something you can actually look at.
What I have built
A dashboard with charts and metrics for thisthese specific questionquestions. Its first version is live and you can open it right now:
https://jorisstrakeljahn.github.io/asmap-dashboard/ https://dashboard.asmap.org/
It walks the full history of published ASmap builds and scores each one against the real Bitcoin network. Instead of arguing about whether an old map still works, you watch its coverage of live nodes fall over time and read the answer straight off the chart.
Removed
Added
It has two sides. One side studies the map files on their own, so you can take any two builds and see which networks moved between them and how much address space changed. The other side is the one I care about most. It takes real observed nodes and measures how the maps actually behave on them. How concentrated the network is across a handful of large providers, how much extra diversity ASmap buys over the naive grouping and how stale a given map has become.
Removed
Added
When my data source disappeared
Getting that live view of the network was the hardest part and it almost did not happen. The plan rested on one data source for the live network, a public crawler called bitnodes.io. In the first week of the program it went offline and never came back. The whole network side of my project depended on it and suddenly it was gone.
What got me out of that hole was other people. fjahr reached out to his contacts and the wider community stepped in. b10c had archived old bitnodes data and shared it. The team at KIT shared what they could. The BitMEX crawler that continues bitnodes today gave me a way forward for the live data. I built one loader that takes all of these. The numbers came back and where the sources overlap they agree almost perfectly.
What that taught me
The real lesson was not technical. It was how fragile the ground under Bitcoin network monitoring actually is. A crawler that a whole class of analysis depended on was run by one person and when they stopped, it was simply gone. bitnodes.io was run by one person. When they stopped, the data was gone. A lot of the data and tooling the ecosystem leans on sits with one maintainer, one server, one person who happens to still care. I ran into that in my very first weeks in open source, on the exact project I was meant to build on.
That changed how I see the work. Tools like this stay alive only if people keep arriving, joining projects and carrying them when others move on. I did not plan my way here. I have been into Bitcoin for over three years and wanted to build on it for a long time, but I never really knew where to start or felt ready to jump into open source. I came across Summer of Bitcoin almost by accident and without it I probably would not have started at all, or found the courage to take part. Now I see it as a rare chance to actually contribute, by helping keep a small but real part of Bitcoin maintained. Programs that bring new people in matter. So do people like fjahr and jurraca, who are willing to spend their time pulling someone new into open source and helping them grow into it. Without that, projects quietly fade. With it, they get a next generation.
The next step is to make the dashboard update itself every day and give it a proper home on a subdomain of asmap.org.
So thanks to them and to the Summer of Bitcoin team, for that opportunity.
If you work with ASmap, run a node, or just find this interesting, I would really like to hear from you. The dashboard is a first version and feedback is what makes it better, so try it out and tell me what is missing or wrong. The best place to reach me is the feedback thread linked below.
Links
Measuring ASmap and Learning How Fragile Open Source Really Is
This is a copy of my Summer of Bitcoin midterm report from June 27, 2026. The original is on the Summer of Bitcoin blog.
When people talk about Bitcoin security they almost always picture mining. Hash rate, energy, warehouses full of machines. Who each node connects to gets far less attention, even though those choices are how it keeps itself from being eclipsed.
A node keeps only a small number of outbound connections. If someone can fill all of those slots with machines they control, they can feed that node a false view of the chain, hide transactions from it, or cut it off from the rest of the network. This is the idea behind an eclipse attack and the defense is easy to state. Connect to peers that sit in different parts of the internet.
Spreading them out is harder than it sounds. The straightforward approach groups peers by their IP prefix, but a cloud host like AWS, or a large ISP, can own thousands of prefixes and still look like many separate peers. ASmap fixes that. It groups every address by the autonomous system that actually owns it, so one provider counts as one group no matter how many addresses it holds. The feature has been in Bitcoin Core since 20.0. Since 31.0 every release ships with a map embedded.
Here is the part that pulled me in. ASmap has been worked on for years, yet two questions stayed open. Once a map is shipped inside a release, when has it aged so much that it becomes a liability? And when a new map is built, how do you tell whether it is an improvement or a regression?
I am Joris, a student and contributor in Summer of Bitcoin 2026, mentored by fjahr and jurraca. My project turns those questions into something you can actually look at.
What I have built
A dashboard with charts and metrics for these questions. Its first version is live and you can open it right now:
It walks the full history of published ASmap builds and scores each one against the real Bitcoin network. Instead of arguing about whether an old map still works, you watch its coverage of live nodes fall over time and read the answer straight off the chart.
It has two sides. One side studies the map files on their own, so you can take any two builds and see which networks moved between them and how much address space changed. The other side is the one I care about most. It takes real observed nodes and measures how the maps actually behave on them. How concentrated the network is across a handful of large providers, how much extra diversity ASmap buys over the naive grouping and how stale a given map has become.
When my data source disappeared
Getting that live view of the network was the hardest part and it almost did not happen. The plan rested on one data source for the live network, a public crawler called bitnodes.io. In the first week of the program it went offline and never came back. The whole network side of my project depended on it and suddenly it was gone.
What got me out of that hole was other people. fjahr reached out to his contacts and the wider community stepped in. b10c had archived old bitnodes data and shared it. The team at KIT shared what they could. The BitMEX crawler that continues bitnodes today gave me a way forward for the live data. I built one loader that takes all of these. The numbers came back and where the sources overlap they agree almost perfectly.
What that taught me
bitnodes.io was run by one person. When they stopped, the data was gone. A lot of the data and tooling the ecosystem leans on sits with one maintainer, one server, one person who happens to still care. I ran into that in my very first weeks in open source, on the exact project I was meant to build on.
That changed how I see the work. Tools like this stay alive only if people keep arriving, joining projects and carrying them when others move on. I did not plan my way here. I have been into Bitcoin for over three years and wanted to build on it for a long time, but I never really knew where to start or felt ready to jump into open source. I came across Summer of Bitcoin almost by accident and without it I probably would not have started at all, or found the courage to take part. Now I see it as a rare chance to actually contribute, by helping keep a small but real part of Bitcoin maintained. Programs that bring new people in matter. So do people like fjahr and jurraca, who are willing to spend their time pulling someone new into open source and helping them grow into it. Without that, projects quietly fade. With it, they get a next generation.
The next step is to make the dashboard update itself every day and give it a proper home on a subdomain of asmap.org.
So thanks to them and to the Summer of Bitcoin team, for that opportunity.
If you work with ASmap, run a node, or just find this interesting, I would really like to hear from you. The dashboard is a first version and feedback is what makes it better, so try it out and tell me what is missing or wrong. The best place to reach me is the feedback thread linked below.