seed.thelionpool.org

A DNS seed for post-fork Bitcoin Knots nodes. This page documents how the seed is operated, as encouraged by point 6 of doc/dnsseed-policy.md.

Last updated 2026-10-05

Operator

Lionel Wardhaugh
GitHub: LionThunderFingers
Contact: knots.seed@gmail.com

What it serves

Network: Bitcoin, post-fork. Fork height 961640.
Software: LionSeed, a DNS seeder written from scratch for the Bitcoin network (Rust, MIT licence). It is a live crawler, not a static host list. It crawls clearnet, Tor v3 and I2P nodes. Source: https://github.com/LionThunderFingers/LionSeed
Seed hostname: seed.thelionpool.org
Authoritative nameserver: ns-seed.thelionpool.org (185.183.159.199)
Transport: UDP and TCP on port 53. A, AAAA, NS and SOA records.
DNS TTL: 60 seconds for A and AAAA answers, so clients get a fresh selection often. NS and SOA records use 40000 seconds.
Hosting: A dedicated VPS located in Germany. Monitored with external alerting.

Only post-fork nodes, under any query

Every service-bit filter of the form x<hex> is accepted, for example x10000009 (NODE_NETWORK|NODE_WITNESS|NODE_BLAKE2B) or x9. A bare hostname query uses x9.

Whatever the filter, the only nodes that can ever appear in an answer are nodes this seed has itself confirmed to be post-fork. So a bare or x9 query never returns a pre-fork node. This is a deliberate deviation from stock seeder behaviour.

The reason: post-fork nodes share port 8333 with the much larger SHA256d network. An unfiltered answer would be composed mostly of peers that are useless to a post-fork node.

How nodes are chosen

A node is served only when all of these hold:

The seed completed a handshake with it and the node advertised NODE_BLAKE2B (service bit 28) in its own version message. Service bits gossiped by other peers are never trusted on their own.
It reported a height of at least 961640 and advertises NODE_NETWORK.
It answered a handshake within the last hour. Post-fork nodes are re-checked every 15 minutes, so a node that goes away drops out of answers quickly.
It has a good reliability record over recent checks.

Each answer is a random selection of up to 24 of these nodes, at most one per /16 (IPv4) or /32 (IPv6) network, so no single provider can fill an answer. DNS answers carry clearnet addresses only. Tor and I2P nodes are crawled for the census and the crawl data, since DNS cannot carry those addresses.

The seed does not filter by user agent or node version. Any node that follows the post-fork consensus rules is treated the same.

How to use it

Query the seed directly:

dig +short x10000009.seed.thelionpool.org

Or point a node at it:

bitcoind -seednode=seed.thelionpool.org

Current figures

This page describes how the seed is run and carries no numbers that change. Node counts and other current figures are on the census.

Software

The seed has run LionSeed since 2026-09-27 at 21:28 UTC. Before that it ran a patched fork of sipa/bitcoin-seeder. The seed hostname, nameserver and IP address did not change.

LionSeed re-checks post-fork nodes every 15 minutes. Addresses it has not tried yet come next, then addresses it tried but could not classify, retried every 6 hours, then pre-fork nodes, checked once a day. It asks each node for addresses at most once a day.

Policy compliance

Against doc/dnsseed-policy.md:

Results are crawled live. They are not biased or filtered per requester.
Each answer is a randomly selected subset of the currently good set, so two queries will usually differ. No requester or group of requesters is singled out to receive different results.
TTL is 60 seconds, the minimum the policy asks for.
DNS queries are not logged at all. The only per-requester state is a short-lived in-memory counter used for rate limiting, which is never written to disk.
Crawl data, meaning which nodes were reachable and when, is published through the census (point 5). It is not made more complete by biasing connectivity.
A contact address is published here, and is also in the zone's SOA RNAME.

No compliance is claimed beyond the points listed above.