Payment Correlation Attack

What Is a Payment Correlation Attack?

A payment correlation attack is a privacy attack against the Lightning Network in which an adversary links the sender and receiver of a payment by correlating data observed at different points along the payment route. The most well-known variant exploits the fact that every hop in a standard Lightning payment carries the same payment hash, giving any observer present at two or more hops a trivial way to confirm they are handling the same payment.

Although onion routing encrypts per-hop instructions so that each forwarding node sees only its immediate predecessor and successor, the payment hash is visible in the HTLC at every hop. This means the privacy guarantee of onion routing is weaker than it first appears: a single entity operating two or more nodes on the same path can defeat the anonymity that onion encryption is designed to provide.

Research by Kappos et al. (2020) and Romiti et al. (2020) demonstrated that even a modest number of adversarial nodes can deanonymize a significant fraction of Lightning payments through hash correlation alone. A 2021 analysis published at the ARES conference found that a single adversarial node on a payment path could uniquely identify at least one of the sender or receiver in roughly 70% of observed transactions, and multiple colluding nodes could identify both parties in nearly all cases.

How It Works

To understand the attack, consider how a normal Lightning payment flows through the network:

1. The receiver generates a random preimage and computes its SHA-256 hash (the payment hash)
2. The receiver includes this hash in a Lightning invoice
3. The sender constructs an onion-encrypted route and sends an HTLC locked to this hash through each intermediate node
4. Every forwarding node along the route sees the same payment hash in the HTLC it receives and the HTLC it forwards
5. The receiver reveals the preimage, and settlement propagates backward through the route

The vulnerability is in step 4. Each forwarding node sees the identical hash value. An adversary operating nodes at positions 2 and 5 on a seven-hop route can compare hashes, confirm they are handling the same payment, and conclude that the sender is somewhere before position 2 and the receiver is somewhere after position 5.

Hash Correlation

Hash correlation is the most direct form of the attack. Because the payment hash is a 32-byte value shared across all hops, matching is deterministic: if two nodes see the same hash within a plausible time window, they are on the same payment route. There is no ambiguity or false-positive risk.

# Adversary node A sees:
HTLC incoming: hash=a1b2c3...  amount=500,100 sat  from=NodeX
HTLC outgoing: hash=a1b2c3...  amount=500,050 sat  to=NodeY

# Adversary node B (3 hops later) sees:
HTLC incoming: hash=a1b2c3...  amount=499,950 sat  from=NodeP
HTLC outgoing: hash=a1b2c3...  amount=499,900 sat  to=NodeQ

# Same hash → same payment → sender is before A, receiver is after B

If the adversary's node A is the first hop and node B is the last hop before the receiver, the attack fully deanonymizes both parties.

Timing Analysis

Even without hash reuse, timing patterns leak information. A 2024 peer-reviewed paper by Ndolo and Tschorsch demonstrated that a network-level observer can determine a node's role in a payment path based on timing, direction of flow, and message type. An earlier study showed that a passive adversary can infer how many hops separate it from the payment destination by measuring the round-trip time between forwarding an HTLC and receiving the preimage response.

Research published in 2026 by TU Dresden, accepted in ACM Transactions on Internet Technology, showed that a network-level adversary (such as a malicious autonomous system or ISP) can identify and interfere with Lightning payments routed through its infrastructure by examining packet headers alone, without needing to operate any Lightning nodes.

Amount Correlation

Payment amounts decrease slightly at each hop due to routing fees. An adversary observing two points on a route can compare amounts: if two HTLCs have nearly identical values (differing only by the cumulative fees of intermediate hops), they are likely the same payment. Amount correlation is slightly less precise than hash correlation because fee structures vary, but it remains a powerful signal when combined with timing data.

Attack Scenarios

Colluding Routing Nodes

The most practical attack scenario involves an entity operating multiple routing nodes across the network. Because Lightning routing tends to favor well-connected, high-capacity nodes, a well-funded adversary can position nodes at network chokepoints where they intercept a disproportionate share of traffic. Each payment that passes through two or more of their nodes is fully correlated.

Wormhole Attack

A wormhole attack is a variant where two colluding nodes on the same route share the payment preimage directly, bypassing the honest intermediate nodes between them. The colluding nodes settle the HTLC chain between themselves and steal the routing fees that honest intermediaries would have earned. This attack relies on hash correlation to identify which payments to target.

Network-Level Surveillance

An adversary at the network layer (ISP, autonomous system operator, or state-level actor) can observe encrypted Lightning traffic without running any nodes. While they cannot read onion payloads, packet timing, sizes, and connection patterns reveal payment flows. Noise protocol encryption protects message contents but does not hide these metadata patterns.

Mitigations

PTLCs (Point Time-Locked Contracts)

PTLCs are the primary proposed solution to hash-based correlation. Instead of locking each hop to the same hash, PTLCs use adaptor signatures with a different elliptic curve point at each hop. Each forwarding node sees a unique lock value that cannot be linked to the values seen by other nodes.

PTLCs require Schnorr signatures, which became available on Bitcoin with the Taproot upgrade. However, Lightning-level PTLC adoption requires updates across all major implementations and remains in active development. For a deeper analysis, see the research article on PTLCs and Lightning's privacy future.

Blinded Paths

Blinded paths protect the receiver's identity by encrypting the final portion of the payment route. The receiver constructs a blinded route from an introduction point to their node, and the sender routes to the introduction point without learning who or where the receiver is. This technique was specified in BOLT 4 (route blinding, merged March 2023) and is foundational to BOLT 12 offers.

Blinded paths address receiver-side correlation: even if an adversary identifies the sender, they cannot determine the final destination. The tradeoff is that longer blinded segments increase fees and reduce payment reliability. For details on how blinded paths work, see the research article on blinded path privacy.

Multipath Payments

Multipath payments split a single payment across multiple routes. While this does not eliminate hash correlation (each partial payment still carries the same hash), it forces an adversary to have presence on all paths to see the full payment amount. Combined with PTLCs, multipath payments would use different points on each path, providing strong protection against correlation.

Constant-Size Messages and Dummy Traffic

Researchers have proposed padding all Lightning messages to a constant size and injecting dummy traffic to prevent timing and message-size analysis. These techniques borrow from mixnet design but carry bandwidth and latency costs that make them impractical at scale without careful engineering.

Why It Matters

Payment correlation attacks directly undermine the privacy assumptions that many Lightning users take for granted. While onion routing prevents individual forwarding nodes from seeing the full path, correlation attacks reconstruct that information from multiple vantage points. This has practical implications:

• Merchants using Lightning can have their customer payment patterns exposed to surveillance
• Users in jurisdictions with financial censorship risk having their transactions linked to their identity
• Routing node operators who believe they are providing a private service may inadvertently participate in deanonymization when colluding nodes are present on shared routes

Spark takes a fundamentally different architectural approach. Instead of routing payments through a multi-hop channel network, Spark uses a statechain-style model where ownership of Bitcoin is transferred by rotating cryptographic key shares between sender and receiver, coordinated by a distributed set of operators. Because payments do not traverse a series of independent forwarding nodes, there is no multi-hop route for an adversary to observe and no shared payment hash exposed across hops. This eliminates the attack surface that makes payment correlation possible on channel networks. For more on Spark's design, see the Spark architecture overview.

For a broader analysis of Lightning privacy challenges, see the research article on Lightning Network privacy.

Risks and Considerations

Defense-in-Depth Required

No single mitigation eliminates all correlation vectors. PTLCs solve hash correlation but not timing or amount correlation. Blinded paths protect receiver identity but not sender identity. Effective privacy requires layering multiple defenses, and even then, a sufficiently resourced adversary with network-level visibility may still extract useful information.

Privacy-Jamming Tradeoff

Cryptographer Lloyd Fournier has noted that making payment correlation harder can make channel jamming easier. If forwarding nodes cannot tell whether two HTLCs belong to the same payment, they also cannot detect certain abuse patterns. Protocol designers must balance privacy improvements against denial-of-service resistance.

Deployment Timeline

PTLC adoption depends on Taproot channel support across Lightning implementations, which remains in progress. Blinded paths are available in some implementations but not universally supported. Until both are widely deployed, hash correlation remains a practical attack against most Lightning payments.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.