Repository navigation
net: Fixed seeds predate the proof-of-work change and only two DNS seeds serve BLAKE2b nodes #395
Description
Symptom
Fresh 29.4.1 installs report they cannot find peers on mainnet. The cause is the network's bootstrap, not the user's setup.
Measured on 2026-09-06
- Of the nine mainnet DNS seeds, two serve BLAKE2b nodes:
dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us(22 addresses) andseed.bitcoin.haf.ovh(25). The union is 42. The other seven return nothing forx10000009.<seed>, which is correct, they carry no BLAKE2b nodes. contrib/seeds/nodes_main.txt(and sosrc/chainparamsseeds.h) was last regenerated from a 2026-08-01 crawl (net: Update mainnet seeds and scripts #348, merged 2026-08-07), before the proof-of-work change at 961640 on 2026-08-30. The compiled-in fixed seeds are therefore almost entirely SHA256d nodes, which is what a node falls back to after 60 seconds when DNS is thin or blocked. They share the port and network magic, so the node connects and learns nothing about this chain.contrib/seeds/makeseeds.pyalready requiresNODE_NETWORK | NODE_WITNESS | NODE_BLAKE2B(0x10000009), but its 50% 30-day uptime filter cannot pass any node that joined at the change until the end of September.
Fix
#394 regenerates the list from today's seeder dumps (Luke's, Léo Haf's, sipa's, 21.ninja's and achow101's) with the change height as the block minimum and a 7-day uptime window, and adds that window as an option to makeseeds.py. 127 entries, 50 of the 59 clearnet ones answered on their port when generated.
Workaround until a release carries it
Add a few current BLAKE2b nodes to bitcoin.conf and restart. seednode connects once to learn peers and then disconnects; it does not pin a permanent link. Remove the lines once getpeerinfo shows peers whose servicesnames includes BLAKE2B.
seednode=101.100.139.249
seednode=104.195.201.236
seednode=120.159.141.21
seednode=129.228.37.230
seednode=135.180.233.81
seednode=136.28.10.242
These are public nodes returned by the two BLAKE2b DNS seeds, reachable on 8333 at 2026-09-06 15:02Z; they will change. Confirm you are on this chain with getblockchaininfo (tip past 961640).
Remaining ask
Two productive DNS seeds is a single point of fragility for the whole network's bootstrap. More operators running a hardfork-seeding (x10000009) DNS seed, added to chainparams, would harden it.
Edit: wording only, "the fork" replaced with "the proof-of-work change" and "BLAKE2b nodes" throughout. Nothing else changed.
Activity
[-]net: Fixed seeds predate the fork and only two DNS seeds serve BLAKE2b nodes[/-][+]net: Fixed seeds predate the proof-of-work change and only two DNS seeds serve BLAKE2b nodes[/+]LionThunderFingers commentedon Sep 22, 2026
I've been running a BLAKE2b DNS seed since 2026-09-18 on a VPS in Germany... deliberately a different provider from the existing seeds. It's seed.thelionpool.org.
dig +short x10000009.seed.thelionpool.org
Live crawler, not a curated list: 24 records per reply, 90ish distinct over 15 consecutive queries. It's currently tracking 410 BLAKE2b nodes, 136 reachable... It gives off pretty interesting data so I got the clanker to make a dashboard which you can go see at: https://lionthunderfingers.github.io/B2B-Node-census/ ... It updates hourly so not live data.
The code is at https://github.com/LionThunderFingers/BTC-blake2b-seeder
It's a fork of the sipa/bitcoin-seeder with BLAKE2b support plus a Debian 13 deploy script, so other people don't have to repeat the setup.
I'm still just running it for a while and testing it before I ask to be added to chainparams (not sure how to do that) but anyway, before I do any of that is this the kind of thing you're looking for?
LionThunderFingers commentedon Sep 28, 2026
Quick update on seed.thelionpool.org... I replaced the sipa fork with a seeder written from scratch for the blake fork https://github.com/LionThunderFingers/LionSeed
The old one worked through one queue shared with the whole SHA256d network, so fork nodes kept getting starved and dropping out of answers. LionSeed re-checks fork nodes every 15 minutes, only serves nodes that proved bit 28 in their own handshake and answered in the last hour, and it also crawls Tor and I2P now.
Right now it's seeing 921 fork addresses (368 clearnet, 399 I2P, 154 onion) with 628 of them rated good. Those are addresses not nodes, one node can be reachable on more than one network. How the seed is run: https://lionthunderfingers.github.io/B2B-Node-census/seed/
The census is still at the same place, https://lionthunderfingers.github.io/B2B-Node-census/ it's just built from the new seed's data now, and it counts Tor and I2P nodes too.
For #394, the fork nodes from the dump are published in the usual seeds.txt format and makeseeds.py takes it as is: https://lionthunderfingers.github.io/B2B-Node-census/seeds.txt it updates hourly if it's any use for the next fixed seeds regen or tests you might want to do. Just give it a few weeks to level out... the numbers right now might be weird.
chainparams: add seed.thelionpool.org to mainnet vSeeds
chainparams: add seed.thelionpool.org to mainnet vSeeds
chainparams: add seed.thelionpool.org to mainnet vSeeds
chainparams: add seed.thelionpool.org to mainnet vSeeds