Network and Lightning
Six P2P-network threads and five Lightning items from this window
WHAT'S IN HERE
A clear theme across the network items: operators measuring the network rather than just running on it. BNOC and Delving carried six threads that each look at a different angle - reachability behind NAT, how similar nodes' address books are, a one-day Tor surge, a novel back-to-back mining fork, surveillance Electrum servers, and the loss of Bitnodes as a historical reference. On the Lightning side: a CLN remote-crash disclosure, three concurrent release candidates, and a public conversation about how much money a routing node actually makes.
NETWORK ITEMS
TCP hole punching, addrman overlap, Tor spike, back-to-back forks, Electrum monitoring, Bitnodes data.
LIGHTNING ITEMS
CLN assertion DoS, CLN v26.06 RCs, LND v0.21.0 RCs, routing economics.
TCP Hole Punching for Home Nodes
0xB10C, Delving Bitcoin, 2026-05-11
THE PROBLEM
Most home Bitcoin nodes sit behind a NAT router and so are unreachable from the public internet: they can dial out, but no one can dial in. NAT-PMP/UPnP hasn't materially moved the needle. TCP hole punching coordinates two such nodes through a third-party "matchmaker" so both fire SYN packets at each other simultaneously, opening NAT mappings in both directions.
PROTOCOL HOOKS DISCUSSED
- A new service flag (e.g.
NODE_HOLEPUNCH) to advertise capability. - ADDRv2 extensions linking a clearnet endpoint to a Tor/I2P coordinator.
- BIP-324 initiator/responder semantics for "punched" connections.
OPEN CONCERNS
- Effectiveness depends on the kind of NAT your router does. Friendly NATs (the ones that re-use the same external port for the same internal port) work fine; the strict ones that pick a new external port for every destination break the trick. Many home routers are the strict kind.
- Coordination via a Tor/I2P endpoint risks linking clearnet + onion identities.
- TCP hole punching is flakier than UDP; iroh sees 90%+ on UDP via federated relays.
STATUS
Research phase, "more open questions than answers". @willcl-ark has a Python PoC (
natcat); @sipa has a demo (holeroulette) with a live signet matchmaker; b_5 and @cedarctic contributed UDP / iroh data points.Addrman Overlap Study
stratospher, BNOC, 2026-05-19
WHAT WAS MEASURED
Every Bitcoin Core node keeps an on-disk address book - internally called
addrman - that records peers it has heard about (the "new" table) and peers it has actually connected to (the "tried" table). stratospher pulled those tables from nine cooperating nodes and asked: how much does each node's view of the network actually overlap with everyone else's?NEW TABLE (GOSSIP-DRIVEN)
~44-50% overlap among clearnet-only nodes; ~50% among multi-network nodes; ~8-11% between an onion/i2p-only node and the clearnet cluster.
TRIED TABLE (HISTORY-DRIVEN)
~50% within the clearnet cluster, ~37% in the multi-network cluster, 27-37% cross-cluster.
STANDOUT FINDING
76% of one node's tried entries also appeared in another's addrman, but tried-table similarity was only ~37% - they had the same pool, different luck.
CONCLUSION
Address discovery is shaped strongly by which networks a node speaks; far from random.
Tor Address Spike
Matthias, BNOC, 2026-05-20
WHAT WAS SEEN
A Tor-connecting Bitcoin node (configured like the DSN Research Group's network monitor) saw reachable Tor peers climb from a baseline ~16,000 to about 33,000 on 2026-05-09, in multiple steps over the early-May window. The count fell back to baseline on 2026-05-10 just as abruptly.
FINGERPRINT
Every new peer in the spike advertised user agent
Satoshi:31.0.0 and service flags 3080 (NODE_WITNESS | NODE_NETWORK_LIMITED | NODE_P2P_V2) - a strikingly uniform set.EXPLANATION
The post offers no theory. The pattern (uniform UA, identical flags, simultaneous on/off across one day) is consistent with a coordinated batch of nodes brought up and torn down together, but the data alone does not confirm that.
Back-to-Back Forks at 949203-949204
2026-05-13, logged by 0xB10C / fork-observer.com
WHAT HAPPENED
Three major pools produced competing blocks across two consecutive heights:
- Height 949203: Foundry USA and ViaBTC mined parallel blocks.
- Height 949204: ViaBTC and MARA Pool mined parallel blocks.
WHY IT'S NOVEL
This is not a two-block reorg - no chain rolled back. It is a back-to-back fork where multiple pools published competing siblings at consecutive heights and the network had to choose at each. 0xB10C flagged the pattern as previously undocumented; the event was tracked live on fork-observer.com.
WHAT IT SUGGESTS
Heavy concentration plus tight propagation timing produces these "near-miss" patterns more often than the textbook orphan-rate model assumes. Worth watching as Foundry, AntPool, and ViaBTC remain ~60% of hashrate.
Spotting Spy Electrum Servers
dutenrapha, BNOC, 2026-05-28 (b10c's original prompt)
THE QUESTION
b10c asked publicly: can the network spot "spy" public Electrum servers - those that surveillance firms (Chainalysis et al.) might be running to log address queries? The working hypothesis: a cheap way to deploy many such servers is to back them all by the same Bitcoin node, which would make their mempool views nearly identical.
METHOD
Every five minutes, ask every public Electrum server listed at
1209k.com/bitcoin-eye for its mempool fee histogram (via mempool.get_fee_histogram). Then compare every pair of histograms using a standard statistical "how different are these two distributions?" score - Jensen-Shannon Divergence (log base 2, so JSD is bounded [0, 1]). Servers whose histograms stay near-identical (JSD ≤ 0.5) cluster together, a likely sign of a shared backing node.EARLY FINDINGS
59 of 96 registered servers respond; 5 stable clusters persist across timestamps. Most server pairs report identical histograms (JSD = 0). Cluster 1 groups servers that look operationally unrelated - but it could also just reflect identical mempool-policy defaults.
CAVEAT
Tor servers are excluded in this first version. The author flags that matching histograms could indicate shared infrastructure or simply identical implementations - the test is suggestive, not conclusive.
Bitnodes Data Request
fjahr, BNOC, 2026-05-13
STATE OF PLAY
fjahr wants historical Bitnodes snapshots to study how each new asmap file has affected network topology over the past two years. The post opens with the plain statement: "Bitnodes is dead" - the long-running network-crawl service appears to have gone offline with no announced cause.
ALTERNATIVES OFFERED
- KIT (DSN) historical data exists but IPs are anonymised under German data-protection law - not useful for asmap analysis.
- b10c: holds 200+ GB of snapshots back to 2025-07-10.
- Matthias (KIT): can share non-anonymised files for specific dates.
- CedArctic: shared a 2025-06-26 snapshot.
WHY IT MATTERS
Without Bitnodes, the community loses its main public historical record of the reachable-node graph. The thread is effectively a community archive scramble - and a useful reminder that load-bearing infrastructure built by one person can disappear.
CLN Assertion DoS
Chand-ra (Summer of Bitcoin 2025 intern), disclosed 2026-05-16
THE BUG
During the channel-opening handshake, a malicious peer could send the funding transaction id as all zeros. CLN's signing daemon had an internal sanity check that crashed the whole process when it saw that input - turning a malformed message into a free node-takedown. The handshake gets that far without any prior peering or trust, so any node on the network could be the trigger. Source:
handle_setup_channel() in hsmd/libhsmd.c.SEVERITY
Medium/high DoS, remote, no special peering required. Versions before v26.04 are vulnerable; v26.04 ships the fix.
DISCLOSURE TIMELINE
- 2025-07-11 - fuzzing target released.
- 2025-07-24 to 28 - bug confirmed and reported by Chand-ra.
- 2025-08-04 - fix confirmed by maintainers.
- 2025-08-07 - fix merged to master.
- 2026-05-16 - public Delving disclosure.
TAKEAWAY
A reminder that fuzzing pays off (the report came directly from a fuzzing intern's target), and that
assert() on attacker-controlled inputs is itself a DoS vector. Operators should be on v26.04 or later.CLN v26.06 Release Candidates
rc1 2026-05-12, rc2 2026-05-22
HEADLINE: xpay TAKES OVER pay
From v26.06,
xpay handles the long-standing pay command by default and processes invoices returned by invoicerequest(). Operators that want the old behaviour can set xpay-handle-pay=false. pay itself is being deprecated but still works via delegation.NEW IN RC1
graceful- prepare CLN for clean shutdown.sendamount- pay specifying amount-to-send rather than amount-to-receive.xkeysend- keysend with modern routing support.createproof- BOLT12 payment-proof JSON-RPC.- BOLT-protocol channel close timeout up from 12 to 72 blocks.
CHANGES IN RC2
- Payment-proof implementation updated to the latest draft.
- gossipd hardened against channel_update spamming.
- Stale field cleanup in docs and gRPC.
BREAKING
message-padding is now off by default (it was breaking interop with some peers). If you run plugins or integrations that assumed the old default, retest them on rc2.LND v0.21.0 Release Candidates
rc1 2026-04-22, rc3 2026-05-29
HEADLINE: NATIVE SQL PAYMENT STORE
v0.21.0 lands the migration of LND's payment store from the legacy KV format to native SQL (issue
lnd#9861). The migration runs only when both --db.use-native-sql and --db.backend are set to sqlite or postgres; operators not yet ready can stay opted-out with --db.skip-native-sql-migration.WHY IT MATTERS
Native SQL means LND can ask the database "find payments matching X" and get an answer in milliseconds, rather than scanning the whole payment history from disk every time. For routing nodes with years of accumulated payments, that's the difference between sub-second queries and multi-minute startups. Postgres support keeps multi-host setups (LND on one box, database on another) viable.
RELEASE CADENCE
rc1 on 2026-04-22, rc3 on 2026-05-29. Compiled with
go1.25.5; reproducible build tags include all the usual subsystems (autopilot, signer, wallet, invoices, neutrino, router, watchtower, peers, monitoring, plus kvdb_postgres / kvdb_etcd / kvdb_sqlite).Lightning Routing Economics
May 2026 community data and observations
THE NUMBERS BEING DISCUSSED
A short-form Delving post and several public write-ups put concrete numbers on what well-run routing nodes earn. The headline framing: routing capital is turned over many times per year, so even small per-hop fees compound into meaningful annualised returns - and unlike traditional yield, no leverage is involved.
CAPITAL VELOCITY
Total deployed liquidity reportedly turns over ~7x annually across the network; on dedicated routing-only capital the figure cited is ~88x.
RETURNS
Professionally managed operators report 5-6% gross annualised at zero leverage. Comparable returns in banking require ~10× leverage.
NETWORK SIZE
Public capacity has now passed 5,600 BTC; total including private channels is estimated above 12,000 BTC.
VOLUME
Estimates put monthly Lightning transaction value over USD 1.1 B as of May 2026.
CAVEAT
These figures are reported by routing-node operators and Lightning service businesses, not measured from public data. The Delving discussion is mainly about whether published returns hold up at smaller node sizes and after rebalancing costs.