₿ WINNOW / CENSUS

DAILY BITCOIN NETWORK OBSERVATIONS

Which Bitcoin peers answer?

We connect to the endpoints in the BTCNodes snapshot using Winnow’s handshake and record the results. See who answers, who advertises compact filters, and which heights they report.

One endpoint is one network address, not necessarily one distinct node.

Loading observations…

01Daily observations

Filter handshakes / attemptsSplit-height reports / filter handshakes

Days without a successful run are left blank. Runs made under the earlier height policy keep their original artifacts.

02What answered

Select an outcome and transport to explore software and endpoint history. Detail dates reflect accepted health observations.

Outcome Endpoints Share of attempts
By transport
Transport Attempts Advertised filters Answered without filters Near tip among filter peers

03Reported software

Software names come from self-reported user agents. “All version responses” includes peers with and without compact-filter support. Near-tip percentages use only the filter-handshake subset.

Family All version responses Filter handshakes Near tip among filter peers Median fee filter

04Download the data

Historical comparison with other censuses 13 September 2026

On 13 September 2026 the same 23,061 responding endpoints were compared with the BTCNodes input: 7,524 advertised compact filters here against 7,526 there, a difference of two. BTCNodes supplies the input list, so this checks consistency with the source rather than confirming the result independently.

Bitnod.es and Coin Dance count deduplicated addresses, and Bitnod.es also keeps addresses that answered recently but not on the day. The most recent 21 Ninja CSV available was from November 2025. These totals measure different things and are not compared directly.

Jonathan Bier, who maintains Bitnod.es, confirmed that it makes its own observations with the shared Bitnodes crawler. Its active count drops addresses last connected nine or more UTC days earlier, excludes I2P, and does not test filter responses, which accounts for several of the differences. The permitted methodology clarification and public CSV overlap are preserved.

Dated comparison, source snapshots and calculations · The two discrepancies, rechecked

05Run the census yourself

The crawler is a small Swift command-line program that uses the wallet’s own connection code. It records version messages, service bits, reported heights and fee filters, and sends nothing about your wallet to anyone.

On macOS with Swift 6, the commands below run a small clearnet sample. Tor and I2P need their own SOCKS routers; the full-run workflow has the exact setup, concurrency and timeouts. 

git clone https://github.com/winnowwallet/census.git
cd census
swift build -c release --product WinnowCensus
curl -fsSL https://btcnodes.io/api/v1/snapshots/latest/ -o snapshot.json
.build/release/WinnowCensus --input snapshot.json --sample 32 \
  --out diagnostic.jsonl --summary-json diagnostic-summary.json

A sample is for checking the tooling and cannot be published in place of a full run. To repeat the cross-census calculation from the stored snapshots: 

python3 scripts/census_compare.py compare comparison/2026-09-13-full

Notes for a rerun

A listening SOCKS port does not mean Tor has finished bootstrapping; the workflow waits for the bootstrap message before dialling. Observations are dated by the day they were made, and reprocessing them later does not refresh them. A timeout records one failed connection attempt from this observer, not that the endpoint is down. Probe duration includes the wait for the peer’s fee filter, so it is not a latency measurement.

Keep the input snapshot and the raw records with any change to the observer, so that a different result can be traced to the network, the timeout, or the code.

Definitions and measurement limits

A successful handshake with NODE_COMPACT_FILTERS means the endpoint advertised compact-filter support. It does not prove that the endpoint returns valid filters; the wallet checks that on the peers it actually uses. A near-tip candidate reported a height within 100 blocks, in either direction, of the reference tip in the input snapshot. A reported height on its own does not identify which chain a peer follows.

The counts are of endpoints, not of distinct machines or operators. One node can have several addresses, ports and transports, and several nodes can share one public address. The clearnet category combines IPv4 and IPv6; Tor and I2P are measured separately. CJDNS and invalid or private addresses are excluded. A timeout describes this observer’s connection attempt, not permanent unreachability.

The downloadable catalog canonicalizes and deduplicates endpoints, applies public-address and network-prefix diversity rules to clearnet, validates overlay addresses, and retains at most 2,000 candidates per overlay. The GUI wallet uses direct clearnet. This census measures Tor and I2P through external SOCKS proxies. A diagnostic sample, or a run whose Tor or I2P router was not healthy, is never published in place of production data. When a run fails, the previous good artifacts stay available with their original observation date.

Probe duration is the elapsed time of a successful filter handshake, including proxy setup where used and the bounded wait for the peer’s fee-filter announcement, so it is not a round-trip latency. A fee filter is the peer’s announced relay threshold, not a fee recommendation or a confirmation estimate. The split-height count records heights 961,632–961,652 and does not by itself prove which chain a peer follows.

See the census source and reproducible comparisons, full run logs and retained raw observations, and Winnow wallet. BTCNodes is the input source, so agreement with its endpoint list is not independent confirmation.