Which software the reachable clearnet nodes KIT was connected to run
87.2%
of the 8,946 peers KIT’s monitor was connected to at advertised Bitcoin Core: about, because a node can advertise any user agent
| Software | All8,946 | Within 24 h2,045 |
|---|---|---|
| Bitcoin Core | 87.2%7,798 | 87.5%1,789 |
| Bitcoin Knots | 11.2%1,003 | 11.5%235 |
| btcd | 0.2%19 | 0.0%0 |
| Other software | 0.8%73 | 0.8%16 |
| Unknown user agent | 0.6%53 | 0.2%5 |
Bitcoin Knots peers, by the service flags they announce
Knots peers · 1,003
| Flags announced | Knots1,003 | All peers8,946 |
|---|---|---|
| BLAKE2b flag | 40.7%408 | 4.6%410 |
| Reduced-data flag only | 13.3%133 | 1.6%142 |
| Neither flag | 46.1%462 | 93.2%8,341 |
| Flags not readable | 0.0%0 | 0.6%53 |
Knots’ source defines the BLAKE2b flag as its BLAKE2b hard-fork rules, reduced-data rules included, so a peer announcing both flags counts as BLAKE2b. Flags are self-announced: a node can set any bit, and the desk cannot see which chain a peer follows. The chain the desk’s figures describe →
Most reachable nodes in the snapshot say they run Bitcoin Core. Bitcoin Knots is the next largest. Since 29.3.knots20260508 its releases include the BIP 110 soft fork, and since 29.4.1 a hard fork to BLAKE2b proof of work; Bitcoin Core includes neither.
Clearnet only: no Tor, I2P or non-listening nodes. “Within 24 h” keeps connections begun in the prior day and over-weights nodes that reconnect often.
Calculation + Heuristic · rules: self-reported user agents ·KIT KASTEL DSN Bitcoin Network Monitor (CC BY 4.0 ↗), aggregated by Satoshi Gazette ·snapshot , not yet a daily series ·KIT snapshot ↗
Dates, sources & limits
Dataset sg-node-software, method 1.1.0. Headline population, set on 1 Oct 2026: all connected peers, with the subset whose connection opened within 24 hours beside it.
Each KIT snapshot lists the peers its monitor was connected to when the snapshot was taken, over IPv4 and IPv6 only (no Tor or I2P). KIT documents lastConnect as the beginning of the last connection to the peer, so an old lastConnect marks a long-held connection, not a stale record: peers leave the snapshot when their connection ends, and the protocol latency and relay counts of long-held connections keep changing from one daily snapshot to the next. The connected population is every peer in the snapshot. The opened_24h population keeps only peers whose current connection began within 24 hours of the snapshot; it is recorded beside the connected population, not instead of it, because it over-weights peers that reconnect often.
Each peer is classified by the user agent it advertised, using the rules in ua_rules, first match wins. User agents are self-reported and a node can advertise any string, so the shares count what nodes say they run.
- unknown: No user agent, or one not in the BIP 14 form /name:version/.
- btcd: A btcd:<version> token anywhere, e.g. /btcwire:0.5.0/btcd:0.26.2/.
- knots: First token Satoshi:<version> with a Knots:<version> token after it, e.g. /Satoshi:29.4.2/Knots:20260508/. Comments in parentheses and later tokens are ignored.
- core: Satoshi:<version> as the only name:version token. Comments in parentheses, which Core's -uacomment option adds, are ignored.
- other: Any other well-formed user agent: Satoshi-led strings with a further name:version token (modified builds such as /Satoshi:29.4/Purity:1.0.0/), look-alikes such as /OracleKnots:29.4.2/, and other software.
Each connected peer is also sorted by two service flags in the version message it sent, which KIT records as one services number: NODE_BLAKE2B (bit 28), which Bitcoin Knots' source defines as a node enforcing its BLAKE2b hard-fork rules (BLAKE2b proof of work and the reduced-data rules), and NODE_REDUCED_DATA (bit 27), a node enforcing the reduced-data rules of BIP 110 (src/protocol.h at tag v29.4.2.knots20260508). Bitcoin Core's protocol.h defines neither bit. A peer announces the BLAKE2b flag only, the reduced-data flag only, both or neither; a peer whose services number is missing or unreadable is unknown, never neither. The split is counted over all connected peers and over the Knots peers among them. A flag, like a user agent, is the node's own claim: a node can set any bit, and KIT's file records no chain tip for a peer, so the split counts what peers announce, not which chain they follow. A row recorded before this rule (method 1.1.0) carries the split only when the same KIT snapshot, re-read, matches the row's sha256 and re-derives every count the row holds; otherwise its service_flags is null.
- Knots src/protocol.h, the two flags ↗
- Knots 29.3.knots20260508 release notes, BIP 110 ↗
- Knots 29.4.1.knots20260508 release notes, BLAKE2b ↗
Rows store counts only. A share is printed to one decimal place when its population holds at least 1,000 nodes and to a whole percent below that, so the last printed digit never stands for less than one node.
Snapshot 20260930_121329, KIT’s clock read at UTC+2. File sha256 c73cbef5c4c2a6300f249151c1929aa5f4fd6b534d3418fd68437599c80e3234, so the row can be checked against KIT’s copy.
Per-peer records reduced to daily counts by implementation, IP version, Bitcoin Core release line and two announced service flags, and aggregated by Satoshi Gazette; the opened_24h population is additionally filtered to connections that began within 24 hours of the snapshot. No per-peer data is republished. Cite as: Neudecker, Till; Grundmann, Matthias; Hartenstein, Hannes. Bitcoin Peer-To-Peer Network Monitoring. Zenodo. doi:10.5281/zenodo.14627525.
Snapshots recorded so far
One row per KIT snapshot day recorded, kept as filed; a day not recorded is listed in its place with the reason. The series is in a seven-day trial before it updates daily, so this page shows the newest recorded snapshot, not a live reading.
| Snapshot (UTC) | Connected | Within 24 h | Core | Knots |
|---|---|---|---|---|
| 8,946 | 2,045 | 87.2% | 11.2% | |
| 9,000 | 2,004 | 86.9% | 11.5% | |
| KIT's file held exactly 9,000 peers; this may be a cap, asked of KIT | ||||
| 8,951 | 1,879 | 87.0% | 11.3% | |
Shares are of all connected peers. A day is held and nothing is written when: the newest snapshot is more than 48 hours old by KIT's clock; the file is under 1 MB or is not JSON; any record lacks a readable lastConnect or has one after the snapshot; the clock offset cannot be derived; the snapshot holds fewer than 1,000 peers; a population's count is outside ±25% of the median of the previous seven rows (once three rows exist); or peers with no identifiable user agent are 2% or more of either population.