Payment Probe

What Is a Payment Probe?

A payment probe is a technique used on the Lightning Network where a node sends a payment that is intentionally designed to fail. The sender constructs a valid HTLC with a correct route and amount but uses a random payment hash that does not correspond to any real invoice. The payment travels through the network like a normal payment, testing each hop along the way, until it reaches the destination node, which rejects it because it cannot produce the matching preimage.

The key insight is in how the payment fails. If the probe returns an "unknown payment hash" error from the destination, the sender knows every channel along the route had sufficient liquidity to forward the payment. If the probe fails with an "insufficient funds" error at an intermediate hop, the sender learns that a specific channel could not carry that amount. By sending probes of varying sizes, a node can map out the balance distribution of channels it does not directly participate in.

Probing exists in a gray area: it is a legitimate tool for improving payment reliability and an effective method for surveillance. This dual nature makes it one of the more debated techniques in Lightning Network protocol development.

How It Works

A payment probe follows the same path as a real payment through the onion-routed network, with one deliberate difference: the payment hash does not correspond to any known preimage at the destination.

1. The probing node selects a target route and constructs an onion packet with a random 32-byte payment hash
2. The HTLC propagates hop by hop, with each forwarding node checking only that it has sufficient balance and that the timelock values are acceptable
3. If any intermediate node lacks the balance to forward the HTLC, it returns a failure message (typically TEMPORARY_CHANNEL_FAILURE) that propagates back to the sender
4. If the HTLC reaches the destination, the destination node cannot settle it because the hash does not match any invoice, so it returns UNKNOWN_PAYMENT_HASH
5. The sender interprets the failure type and location to learn about the route's capacity

Interpreting Probe Results

The error code and source reveal different information about the network:

Binary Search for Balances

An attacker (or pathfinding algorithm) can determine the exact balance of a channel through binary search. The process works as follows:

# Binary search to find channel balance
# Target: channel between Node A and Node B
# Known channel capacity: 1,000,000 sats

low = 0
high = 1_000_000

while high - low > 1:
    mid = (low + high) // 2
    result = probe(route_through_A_B, amount=mid)

    if result == "UNKNOWN_PAYMENT_HASH":
        # Amount fits: balance >= mid
        low = mid
    elif result == "TEMPORARY_CHANNEL_FAILURE":
        # Amount too large: balance < mid
        high = mid

# Balance of A->B direction is approximately 'low' sats

With a channel capacity of 1,000,000 sats, this binary search converges in roughly 20 probes (log₂(1,000,000) ≈ 20). Each probe takes only a few seconds, meaning an attacker can determine a channel's balance in under a minute.

Use Cases

Probing is not exclusively malicious. Several legitimate uses make it a standard part of Lightning Network operations.

Pathfinding and Route Selection

Modern Lightning wallets probe candidate routes before sending real payments. By testing several paths with probes first, the wallet can select the route most likely to succeed, reducing payment failures and improving user experience. This is especially important for multi-path payments where the wallet needs to split the payment across routes with known available capacity.

LND, CLN, and other implementations use probing as part of their mission control or payment routing modules. When a probe confirms a route works for a given amount, the wallet immediately sends the real payment along the same path.

Fee Estimation

Probes reveal the actual fees each hop will charge for a specific amount. Since routing fees can change between when a node last synced the network graph and when it attempts a payment, probing provides up-to-date fee information. This allows wallets to show users accurate fee estimates before they confirm a payment.

Node Uptime Monitoring

Routing node operators use probes to check whether peers are online and channels are functional. A probe that returns any error from the destination confirms the entire path is operational. Services that monitor Lightning Network health use probing extensively to track node availability and channel reliability.

Liquidity Management

Operators running routing nodes probe their own channels and competitor routes to understand network liquidity dynamics. This information helps them decide when to rebalance channels, adjust fees, or open new channels. Tools like Loop and autoloop can use probe data to optimize automated liquidity management.

Privacy Risks

The same properties that make probing useful for routing also make it a powerful surveillance tool. Because probes are free (no payment actually settles), an attacker can send thousands of probes to build a detailed picture of the network's balance distribution.

Balance Discovery Attacks

A balance discovery attack uses systematic probing to determine how funds are distributed across a channel. This is problematic because:

• Channel balances reveal payment activity: if a merchant's inbound liquidity suddenly increases, an observer can infer they received a large payment
• Repeated snapshots reveal payment flows: by probing periodically, an attacker can track how balances shift over time, correlating changes with known transactions
• Combined with graph analysis, probing can deanonymize senders and receivers by tracing balance changes across multiple channels simultaneously

Timing Analysis

Probe response times reveal information about the network topology. Closer hops respond faster, and the latency pattern of failed probes can help an attacker determine the physical or network proximity of nodes. When combined with balance probing, timing data narrows down which nodes are involved in specific payments.

Mitigations

The Lightning Network community has proposed and implemented several countermeasures against probing-based surveillance.

Shadow Routing

Shadow routing adds random extra hops to the onion packet beyond the actual destination. From a prober's perspective, the UNKNOWN_PAYMENT_HASH error could come from any node along the extended route, not necessarily the true destination. This makes it harder to pinpoint which node is the intended recipient and obscures the relationship between probe results and specific channels.

Blinded Paths

Blinded paths, introduced as part of the BOLT 12 specification, hide the last several hops of a payment route from the sender. The sender cannot construct probes targeting specific channels near the receiver because it does not know which channels those are. This significantly limits balance discovery attacks against recipients who use blinded paths.

Timing Randomization

Nodes can add random delays before forwarding or failing HTLCs. This noise makes timing analysis less reliable, though it comes at the cost of slightly slower payments. The tradeoff is acceptable for privacy-conscious nodes, but widespread adoption would increase overall payment latency across the network.

Error Obfuscation

Some node implementations allow operators to return generic errors instead of specific failure codes. By returning the same error type regardless of the actual failure reason, nodes prevent probers from distinguishing between "insufficient balance" and other failure modes. However, this also makes legitimate pathfinding less effective, creating a direct tension between privacy and usability.

The Routing-Privacy Tradeoff

Payment probing sits at the center of a fundamental tradeoff in Lightning Network design. Better routing requires more information about channel states, but that same information erodes payment privacy.

Without probing, wallets must send payments blindly, leading to higher failure rates and worse user experience. With unrestricted probing, any node can map the entire network's balance distribution in hours. The ongoing research challenge is finding techniques that give senders enough information to route reliably while preventing adversaries from extracting granular balance data.

Proposals like PTLCs (which replace hash-based locking with point-based locking) may help by making probe responses less informative to third-party observers. Combined with blinded paths and trampoline routing, future Lightning implementations may achieve a better balance between routability and privacy. For a deeper look at how these technologies interact, see the research on Taproot and Schnorr signatures, which enable several of these privacy improvements at the protocol level.

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.