Lightning Payment Probing: How Channel Balance Discovery Affects Privacy and Route Selection

Lightning payment probing is a technique where someone sends payments with intentionally incorrect payment hashes to discover channel balances without transferring any funds. The payment never completes because no valid preimage exists, but the error messages returned along the route reveal whether each channel had sufficient liquidity to forward the amount. This creates a tension at the core of Lightning's design: the same information that degrades privacy also improves routing reliability.

Academic research has demonstrated that a single attacker can discover the exact balance of a channel in under a minute using fewer than 10 probes, at zero cost. Understanding how probing works is essential for anyone building on or evaluating the privacy properties of Lightning channels.

How Payment Probing Works

In a normal Lightning payment, the sender constructs an onion-routed package targeting a specific payment hash. Each hop along the route locks funds in an HTLC, and the payment completes when the recipient reveals the preimage. A probe follows the same process with one difference: the payment hash is randomly generated, so no valid preimage exists anywhere in the network.

When the probe reaches its destination, the final node returns an incorrect_or_unknown_payment_details error because it cannot match the hash to any invoice. This error propagates back to the sender, confirming that every channel along the route had enough balance to forward the probe amount. If instead the probe fails at an intermediate hop with a temporary_channel_failure error, the sender learns that the failing channel lacked sufficient liquidity.

Zero cost, full information: Probing costs nothing because no payment ever settles. The sender's funds are never at risk, and no routing fees are collected. Yet each probe reveals a binary signal about every channel's balance along the tested route.

The Binary Search Algorithm

The most effective probing strategy uses binary search on the channel capacity. The attacker starts with a known range: the balance must be between 0 and the channel's publicly announced capacity (minus channel reserves). Each probe tests the midpoint of the current range, halving the uncertainty with every attempt.

For a channel with capacity c, the attacker maintains lower and upper bounds (b_min and b_max), initially set to 0 and c. Each probe sends amount a = (b_min + b_max) / 2. If the probe reaches the destination, the balance is at least a, so b_min = a. If it fails at the target channel, b_max = a. After n probes, precision reaches c / 2^n.

In practice, this means 7 probes narrow the balance estimate to 1/128th of the channel capacity: better than 1% precision. A 2020 study by Tikhomirov, Pickhardt, Biryukov, and Nowostawski demonstrated probing speeds approaching 1 bit of information per probe message, with 50% of channels fully probed in under 21 seconds.

Error Codes That Enable Probing

The BOLT specification defines distinct error codes for different failure modes, and these distinctions are what make probing possible. The critical pair is:

The specification originally had separate error codes for incorrect_payment_amount and final_expiry_too_soon. An attacker could use these to confirm whether a node was the intended recipient by sending a payment with a correct hash but wrong amount. These were deliberately consolidated into the single incorrect_or_unknown_payment_details error to prevent destination probing. This fix addressed one attack vector but left balance probing untouched.

What Information Does Probing Reveal

Balance probing exposes more than just individual channel states. A systematic attacker can build a comprehensive picture of network-wide liquidity distribution, revealing information that the gossip protocol deliberately keeps private.

• Exact channel balances for both sides of a channel, to sub-1% precision
• Directional liquidity flow patterns across the network
• Payment activity inference: probing a channel before and after a suspected payment reveals the exact amount transferred
• Node income estimation from observed balance changes over time
• Routing capacity maps showing which paths can handle specific payment sizes

The 2019 paper by Herrera-Joancomartí et al. introduced the Balance Discovery Attack (BDA), demonstrating that a basic attack could disclose 89% of all public channel balances, increasing to 98% with two-way probing. Combined with transaction graph analysis, this information can partially deanonymize Lightning payments that were assumed to be private.

Probing is invisible: Failed payments with invalid hashes are indistinguishable from legitimate payment failures. A routing node cannot tell whether a forwarded HTLC is a real payment attempt or a probe, making detection and measurement effectively impossible.

The Routing Benefits of Probing

The same information that threatens privacy directly improves payment success rates. Lightning's pathfinding algorithms must choose routes without knowing channel balances, which means many payment attempts fail on the first try. Pre-flight probing solves this by testing routes before committing real funds.

Pre-flight Probing in Practice

LDK (Lightning Dev Kit) implements native pre-flight probing through its ScoreUpdate trait. Before sending a real payment, the implementation sends probes along candidate routes and records whether each channel had sufficient balance. This creates dynamic upper and lower bounds on channel liquidity that decay over time, reflecting the reality that balances change as other payments flow through the network.

Pickhardt and Richter developed a probabilistic framework modeling the likelihood that a channel can forward a given amount. For a channel with capacity c forwarding amount a, the success probability under a uniform distribution assumption is P(success) = (c - a + 1) / (c + 1). This formula, combined with probing data, reduced failed payment attempts by 20% to 48% depending on protocol-level optimizations.

Fee Strategy Optimization

Routing nodes use balance information to set competitive fee rates. A node with abundant outbound liquidity in one direction can lower fees to attract flow, while a node with depleted balance can raise fees or disable the channel to prevent failures. LND v0.18 introduced inbound fee discounts, allowing nodes to set negative inbound fees as a signal of available liquidity: a form of voluntary balance disclosure that sidesteps the privacy concern by making the information intentional.

Academic Research on Balance Discovery

Multiple research groups have studied Lightning balance probing since 2019. The body of work has evolved from demonstrating feasibility to optimizing attack efficiency to proposing countermeasures.

The Tikhomirov et al. experiment probed 1,628 live channels, sending 12,895 total onion messages over approximately 14 hours. Of the 9,742 main probing messages, 8,256 (84.75%) returned error codes usable for balance estimation. The study achieved nearly optimal probing speed of 1 bit of information per message. Full details are available in their paper on arXiv.

Countermeasures and Defenses

Defending against probing is difficult because the fundamental design of Lightning's routing protocol relies on error messages that distinguish between "not enough balance" and "unknown payment." Every proposed defense involves a tradeoff between privacy and routing efficiency.

Protocol-Level Defenses

Error message unification would merge temporary_channel_failure and incorrect_or_unknown_payment_details into a single generic failure. This eliminates the signal that probing relies on but simultaneously blinds legitimate senders: they can no longer distinguish between a route that lacks liquidity and one where the invoice was invalid, degrading the payment experience.

Route blinding, introduced through BOLT12 offers, lets receivers encrypt the last few hops of a payment route. The sender cannot determine which node is the final destination, and dummy hops can be appended to further obscure path length. BOLT12 was merged into the official Lightning specification in September 2024 and is supported by Core Lightning, LDK, and Eclair.

Application-Level Defenses

Payment Splitting and Switching (PSS), proposed by van Dam in 2023, allows intermediate nodes to split incoming payments across multiple outbound channels rather than forwarding the full amount through a single channel. This introduces noise into the balance signal: the prober cannot determine how much liquidity any individual channel holds because the payment was fragmented. Simulations using real-world Lightning topology showed information gain reduced by up to 62%. A Core Lightning plugin implementation exists.

Just-in-Time (JIT) routing is another approach: when a forwarding node lacks sufficient balance, it performs a circular rebalance rather than returning an error. The prober sees a successful forward regardless of the original balance state, eliminating the information leak. However, JIT routing introduces latency and rebalancing costs for the forwarding node.

The Jamming and Probing Overlap

Channel jamming and probing share infrastructure in ways that make them difficult to address independently. Biryukov, Naumenko, and Tikhomirov demonstrated in 2022 that combining HTLC jamming with probing extracts information that standard probing alone cannot reach: by jamming specific amounts in a channel first, an attacker can probe parallel channels that would otherwise show aggregated balances.

This connection means that anti-jamming defenses also impede probing. Proposals tracked in the Lightning specification include reputation-based forwarding (where nodes with a history of failed payments face higher barriers) and upfront fees for HTLC slot reservation. Both approaches increase the cost of sending many probes, though neither eliminates probing entirely. The hybrid jamming mitigation project continues to evolve as an active area of Lightning protocol development.

Probing Tools and Implementations

Several tools make probing accessible to node operators and researchers. The balance-of-satoshis (bos) toolkit by Alex Bosworth includes a probe command that tests routes from an LND node. His companion probing library exposes subscribeToFindMaxPayable for binary search on maximum sendable amounts and subscribeToMultiPathProbe for multi-path route discovery.

LDK integrates probing natively. Its scoring system maintains upper and lower liquidity bounds for channels based on both probe results and real payment outcomes, with time-based decay to account for balance changes from other network activity. LDK also penalizes channels whose HTLC maximum values exceed 50% of capacity, since such channels are more susceptible to precise balance estimation.

The Fundamental Design Tension

Lightning's probing problem stems from a core architectural choice: channel balances are private state that must be inferred through trial and error. As Tikhomirov et al. observed, this puts the protocol at a suboptimal point where "channel balances are neither well protected nor utilized." Balance information leaks enough to damage privacy but is not openly available enough to fully optimize routing.

Two divergent solutions have been proposed. One direction merges error types to break probing entirely, accepting worse routing performance. The other direction goes the opposite way: creating an explicit balance query API where nodes voluntarily publish liquidity information, trading privacy for dramatically better routing reliability. Neither has achieved consensus, and the current network lives with the tension.

How Spark Sidesteps the Probing Problem

Spark avoids the balance probing problem by design. As a statechain-based protocol, Spark does not use payment channels and therefore has no channel balances to probe. Transfers on Spark involve cryptographic key rotation between users and operators rather than routing payments through a network of liquidity-constrained channels.

This architectural difference eliminates several privacy issues simultaneously. There is no multi-hop routing where error messages leak balance information. There is no public channel graph where capacity is visible. And there are no routing nodes that could observe payment flow patterns. The tradeoff is a different trust model: Spark requires that at least one operator in its threshold signing set remains honest during transfers, while Lightning is fully trustless.

For developers evaluating privacy properties across Bitcoin Layer 2 solutions, the Spark SDK documentation provides technical details on the protocol's transfer mechanics and privacy model. The Lightning privacy analysis offers a broader comparison of information leakage across both protocols.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.