1 Privacy Threat Landscape

Payment channel networks leak information at three distinct layers. Click each layer to expand details about what information escapes, who can observe it, and how severe the exposure is.

🔗
Layer 3 — Channel Layer
Balance probing · capacity inference · topology
CRITICAL
  • Balance Probing
    Attacker sends carefully crafted HTLC payments to infer the exact liquidity distribution in each channel. Binary search converges to 1-sat precision in ~20 probes at near-zero cost.
    Anyone on networkNo trust needed
    CRIT
  • Capacity Inference (ML)
    Machine learning on public gossip data (BOLT #7) can predict balance split with ~78% accuracy — no active probing required.
    Passive observerPublic gossip
    HIGH
  • Graph Topology
    Full channel graph is publicly announced via gossip. Centrality analysis reveals hub nodes, and topology fingerprints nodes even without on-chain links.
    Anyone
    MED
💸
Layer 2 — Payment Layer
HTLC correlation · amounts · timing · fees
HIGH
  • HTLC Correlation (Wormhole)
    In HTLC-based LN, the same payment hash is visible to all intermediate hops. Malicious nodes spanning multiple positions can link sender ↔ receiver. PTLC eliminates this.
    Routing nodesColluding nodes
    CRIT
  • Amount Correlation
    Intermediate nodes see payment amounts. Unique amounts (e.g., exactly 123,456 sat) can be correlated across multiple hops to reconstruct full payment path.
    Routing nodes
    HIGH
  • Fee Pattern Analysis
    Fee deductions reveal position in route. Last hop pays no fee deduction; first hop sees full amount. Together with timing, route length can be inferred.
    Each routing node
    MED
  • Payment Timing
    HTLC lock times are decremented hop-by-hop. A node can bound its position within the route from its observed CLTV value versus network defaults (shadow routing partially mitigates).
    Each routing node
    MED
🌐
Layer 1 — Network Layer
IP leakage · timing · P2P gossip analysis
HIGH
  • IP Address Exposure
    LN peers connect via TCP/IP. Node IP addresses are announced in gossip (node_announcement). ISPs, governments, or passive observers can link IP → node pubkey → identity.
    Direct peersISPPassive network observer
    HIGH
  • Timing Attacks
    Monitoring when a node forwards HTLCs (visible to direct peers as TCP traffic bursts) can infer payment timing. Cross-correlation with other nodes narrows route membership.
    Direct peersPassive observer
    MED
  • P2P Gossip Analysis
    BOLT #7 gossip messages propagate channel announcements with funding txids. Sybil nodes can map gossip propagation to infer network topology and node connectivity.
    Any LN node
    LOW

Information Accessibility by Attacker Position

Your Node Direct Peers LN Network Nodes Public / Blockchain Analysts IP Address Timing HTLC Hash Amount Fee Pattern Chan Graph Channel Caps Funding TXs Critical High Medium Low/Public
Rings show attacker proximity required to observe each data item

2 Balance Probing Attack — Step by Step

An attacker learns the exact liquidity in any channel using binary search over failed HTLCs. Each probe costs nearly nothing (failed payments don't pay routing fees in legacy LN).

STEP 1
Send probe payment
STEP 2
Success → balance ≥ X
STEP 3
Failure → balance < X
STEP 4
Binary search
STEP 5
Cost analysis
Step 1: Attacker Sends Probe Payment

3 ML Balance Inference (Davis et al. 2023)

Machine learning can infer channel balance distributions from public gossip data alone — no active probing required. A Random Forest trained on historical LN snapshots achieves ~78% directional accuracy.

Input Features (Public Information Only)
Channel Capacity — announced in channel_announcement (BOLT #7)
Node Degree — number of public channels per node
Betweenness Centrality — computed from public channel graph
Fee Rates — base fee + proportional rate from channel_update
Channel Age — derived from funding tx block height
Historical Routing Patterns — inferred from observable gossip
Feature Importance — Random Forest
Model Performance
Directional accuracy (which side heavier) 78%
Balance ratio R² score 0.71
Model type Random Forest
Active probing required None
Predicted Balance Distribution — Sample Node
Probability that local balance is in range [x, x+cap/10]
Skewed toward lower end: high-degree hub nodes tend to deplete local liquidity

4 Cross-Layer Deanonymization (Romiti et al.)

Combining on-chain blockchain analysis with off-chain LN gossip allows a passive observer to link Bitcoin UTXOs to LN node identities, IP addresses, and payment patterns — all from public data.

1

On-Chain Blockchain Analysis HIGH

Data used: Bitcoin blockchain — all transactions are public. Channel open transactions create 2-of-2 multisig outputs with a distinctive UTXO pattern. Taproot channels reduce (but don't eliminate) this fingerprint.

What is revealed: Funding UTXO amount, creation time, spending patterns. Can identify likely LN channel opens by heuristic (cooperative vs force-close signatures).

⟶ Identifies candidate LN funding UTXOs on Bitcoin chain
2

LN Gossip Analysis — BOLT #7 CRIT

Data used: LN gossip messages. channel_announcement messages include the funding txid directly — this is by protocol design (proof of on-chain existence).

This creates a direct, explicit link: UTXO → LN channel → node pubkeys of both channel partners. No heuristics needed; it is in the specification.

⟶ Links UTXO to LN node pubkeys (both channel endpoints)
3

IP Address Correlation HIGH

Data used: node_announcement gossip messages include the node's IP address and port. TCP connections between LN peers are directly observable by ISPs or network-level adversaries.

Linking chain: IP address → LN node pubkey → Bitcoin funding address → channel partners. Tor addresses (onion routing) protect against this, but many nodes do not use Tor.

⟶ IP address linked to Bitcoin address and channel partner identity
4

Payment Tracing via Route Hints MED

Data used: BOLT #11 invoices contain route hints that reveal the receiver's channel partners (for private channels). A receiver with one channel exposes that channel partner in every invoice.

Mitigation: Route blinding (BOLT #12 / BLIP-0039) hides receiver hops behind a blinded path. The sender only knows the entry point of the blinded route, not the final recipient node.

⟶ Receiver identity and channel topology partially exposed; BOLT #12 fixes this
80%
of early LN channels linkable to on-chain UTXOs (Romiti 2021)
100%
of channel_announcements include funding txid (by protocol design)
BOLT #12
Route Blinding deployed — addresses receiver deanonymization (step 4)

5 Wormhole Attack Visualization

In HTLC-based routing, a malicious node controlling two positions in a route can steal intermediate routing fees and violate payment atomicity. PTLCs (Point Time-Lock Contracts) eliminate this attack.

Normal Route
Wormhole Attack
PTLC Fix

Honest 4-hop route. Each node forwards the HTLC to the next hop, collecting its routing fee when the preimage propagates back.

Alice (Sender) 100 sat Bob (Honest) +1 sat fee Carol (Honest) +1 sat fee Dave (Receiver) 98 sat recv HTLC H 100 sat HTLC H 99 sat HTLC H 98 sat ← Preimage r propagates back, unlocking funds at each hop
✓ Alice pays 100 sat — Bob earns 1 sat — Carol earns 1 sat — Dave receives 98 sat
✓ All hops see same payment hash H — but in honest scenario this is fine
✓ Atomicity preserved: all HTLCs resolve or none do

Bob controls two nodes (Bob and Bob2). He routes the payment internally, bypassing Carol entirely — collecting Carol's fee while she still pays.

Alice 100 sat Bob (Attacker) Carol (Victim) Bob2 (Bob's node) Dave Receiver HTLC H HTLC H HTLC H HTLC H WORMHOLE Bob routes internally, skipping Carol preimage r Bob2 claims ← Bob claims ← Carol: paid but no routing fee!
✗ Carol forwards the HTLC but Bob2 (also Bob) collects her downstream payment — Carol's channel balance is drained
✗ Bob earns Carol's routing fee without doing Carol's routing work — double-dips on fees
→ Dave still receives payment correctly — only Carol is defrauded
✗ Root cause: same payment hash H visible at all hops — Bob can link his two HTLC positions

With PTLCs (Point Time-Lock Contracts), each hop uses an independent scalar tweak. Bob cannot link his upstream and downstream positions — the wormhole attack is impossible.

Alice Sender Bob Attacker? Carol Protected Dave Receiver PTLC P₁ PTLC P₂ PTLC P₃ P₁ ≠ P₂ ≠ P₃ — Bob cannot link his upstream and downstream HTLCs Each hop adaptor point = base point + hop-specific tweak known only to that node pair
PTLC Fix: Each hop uses a different elliptic curve point derived from the payment point plus a hop-specific scalar tweak. Bob's position between Alice→Bob uses point P₁ = R + t₁·G, and Bob's position between Carol→Bob2 uses P₂ = R + t₂·G. Since t₁ ≠ t₂, Bob cannot correlate the two positions — the wormhole requires knowing both scalars, which is impossible without colluding with the sender. PTLCs are specified but not yet deployed in production LN as of 2026.

6 Privacy Defense Comparison Matrix

Hover or click any cell for a detailed explanation of why a defense addresses (or fails to address) each threat category.

Defense Balance Probing HTLC Correlation Deanonymization Cross-Layer Status
✅ Fully addresses
🔶 Partially addresses
⭕ Does not address

7 Twilight — Differential Privacy for Balance Probing

Twilight adds calibrated Laplace noise to HTLC failure error messages, making it statistically indistinguishable whether a payment failed due to insufficient balance at X vs X+1. Adjust ε to explore the privacy-efficiency tradeoff.

Privacy Parameter ε (Epsilon)
ε = privacy budget 1.0
ε = 0.1 (high privacy) ε = 10 (low privacy)
Attacker confidence interval (±sats) —
Routing success rate degradation —
Probes needed (vs non-DP 20) —

The Laplace mechanism adds noise drawn from Lap(0, 1/ε) to the threshold used in error message generation. Formally, for adjacent balance states b and b+1:

P(response | balance=b) / P(response | balance=b+1) ≤ e^ε

Small ε → strong indistinguishability → more noise → more routing failures as nodes incorrectly report insufficient balance when they have enough. Large ε → weak privacy → less noise → behavior approximates non-private LN.

Twilight (NDSS 2023): Implements this in a TEE (Intel SGX) so the node's own software cannot bias the noisy responses — preventing a malicious node operator from selectively disabling the privacy mechanism for targeted users.

Privacy vs Routing Performance Trade-off
Privacy (1/CI)
Routing Success Rate
Current ε
Laplace Noise Distribution at Current ε
Noise added to balance threshold before generating error message