How this was measured

A watchtower is addressed as pubkey@host:port, and the pubkey is the tower’s identity key — lnd derives it from a separate key family, not from the node’s identity key. So knowing an operator’s node pubkey tells you nothing about their tower, and there is no gossip message that announces one.

That has a hard consequence: the list cannot be scraped from the network graph. It can only be assembled from the places operators publish their own address. Every row in the directory therefore carries the URL where its address was published, and a row without one is not listed. Towers we have heard of and cannot reach are published as unresolved rather than deleted.

Two kinds of row are refused outright. A pubkey that is not a point on the secp256k1 curve cannot be dialled at all, because the handshake needs the remote static key to do a Diffie–Hellman — this caught the example key from lnd’s own watchtower documentation, which has been copied verbatim into dozens of repositories. And documentation placeholders like 1.2.3.4 are templates, not hosts. A tower that never existed, published as fact, is worse than a missing one.

The prober speaks the same wire protocol lnd’s own watchtower client speaks, using lnd’s own packages, so a protocol change surfaces as a compile error rather than as a quietly wrong figure. One probe of one tower, for one channel type:

1  TCP connect              — timed separately from the handshake
2  brontide handshake       — proves we reached the advertised key
3  Init          →  ←  Init — chain hash and feature bits both ways
4  CreateSession →  ← Reply — the tower accepts or rejects our terms
5  StateUpdate   →  ← Reply — one blob uploaded and acknowledged
6  DeleteSession →  ← Reply — the session and its blob removed again

Steps 4, 5 and 6 each need their own connection: lnd’s tower reads Init and then exactly one further message.

The uploaded blob is random bytes of the correct length. The tower cannot read a real blob either — the ciphertext key is derived from the breach transaction id, which is precisely the privacy property that makes coverage unobservable from outside. So a random blob exercises the same code path a real one does: the tower checks its length against the session’s type, writes it, and acknowledges the sequence number. The 16-byte hint is random, so nothing on chain will ever match it and the entry is inert. Then we delete it.

Step 5 is the reason to bother. A tower with a full disk will negotiate a session and fail to store an update — a probe that stopped at step 4 would call it healthy. That is exactly the silent failure this product exists to catch.

The prober’s identity is its own derived key, not the node’s. It never reads a macaroon, never opens an RPC connection, and holds no authority over the node it runs beside.

Session keys are derived per tower, so the key we present is stable: an operator sees one recognisable client rather than a new stranger every hour. If you run a tower and would rather not be probed, block that key and we are gone — or write to us and we will remove the row. Because the key is stable and every probe ends by deleting its session, a tower holds nothing of ours between sweeps.

A probe that failed for our reasons is recorded as a skip and excluded from both the numerator and the denominator of every figure. Most towers here are reachable only through Tor, and if our Tor daemon is down that is our outage, not theirs.

Latency is recorded only where the tower answered. A timeout is not folded in as a very slow success, so a tower that is down has no latency at all and the table prints an em dash rather than a number.

Fourteen towers speak a different protocol — The Eye of Satoshi, which is a JSON REST API rather than lnd’s wire protocol. Probing one with our handshake would report a perfectly healthy tower as dead, so they are listed, marked, and not counted as failures. A prober for them is separate work and would need its own section here before a single figure about one of them is published.

Clearnet towers are dialled directly; onion towers go through three Tor hops that have nothing to do with the tower. Those two numbers are not comparable, and every figure on this site shows which path produced it. Nothing here averages them together.

The published figure is the round trip of the Init exchange after the handshake — one application round trip, no disk. The session and update round trips include the tower’s own write and are recorded separately.

A probe counts as accepting a session if the tower accepted at least one of the channel types we asked for. Which types it accepts is its own column: a tower that takes legacy and refuses anchors is up, and covers nothing anyone has opened in years.

The words protected, safe and secure are not available to this product. A probe establishes that a tower is reachable, accepting and acknowledging. Nothing more is on offer, from us or from anybody.

Hourly. We dial 85 towers — the ones speaking this protocol; the other fourteen are listed and never contacted. Each tower gets a few short connections with one round trip apiece, and one blob written and deleted. Per tower, that is less traffic than a single real client with one active channel generates in the same hour.

Probe results are public and retained indefinitely. They contain nothing about any node other than the towers themselves. The archive also records when we first probed each tower — a 100% figure means nothing without knowing how long we have been watching, so the table shows both.