Probing

What Is Probing?

Probing is a technique for discovering information about Lightning Network channels without actually completing a payment. An attacker sends a payment they know will fail, then analyzes the failure message to learn about channel states along the route.

The core insight is simple: when a Lightning payment fails, the error message often reveals why it failed. If a channel lacks sufficient balance to forward the payment, the error says so. By sending payments of varying amounts and observing which ones fail due to insufficient balance versus other reasons, an attacker can narrow down the exact balance of any channel.

Probing exploits the transparency of Lightning's error handling. The protocol was designed to give senders useful feedback when payments fail, helping them retry with better routes. This same feedback becomes an information leak when deliberately triggered by fake payments.

The technique requires no special access. Anyone running a Lightning node can probe any channel in the network. The cost is minimal: failed payments consume no fees, only the bandwidth and computation to process them.

How Probing Works

A probing attack follows a systematic process to extract balance information from target channels:

1. Generate an invalid payment hash. The attacker creates a random 32-byte value as the payment hash. No one knows the preimage for this hash, so the payment can never complete successfully.
2. Construct a payment route. The attacker builds a route through the target channel they want to probe. The route must pass through that specific channel to gather information about it.
3. Send the fake payment. The payment propagates through the network as a normal HTLC. Each node along the path forwards it toward the destination.
4. Observe the failure. The payment eventually fails. Either a node along the path rejects it due to insufficient balance, or it reaches the destination and fails because no one can provide the preimage.
5. Analyze the error. The failure message indicates where and why the payment failed. An "insufficient balance" error at a specific hop reveals that the channel capacity on that side is less than the payment amount.
6. Binary search for precision. By repeating with different amounts, the attacker can binary search to find the exact balance. If 100,000 sats fails but 50,000 succeeds (fails at destination), the balance is between 50,000 and 100,000.

The entire process takes seconds per channel. Automated tools can probe thousands of channels per hour, building a detailed map of network liquidity.

Types of Probing

Balance Probing

Balance probing targets specific channels to determine their liquidity distribution. The attacker wants to know: of a channel's total capacity, how much sits on each side?

This information is valuable for several reasons. Routing nodes want to know where liquidity exists to optimize their fee strategies. Researchers study liquidity distribution to understand network dynamics. And adversaries can use balance data to track payment flows or identify high-value targets.

Balance probing typically uses binary search. Start with a payment equal to half the channel's capacity. If it fails for insufficient balance, try one quarter. If it succeeds (reaching the invalid hash error), try three quarters. Within 10-15 probes, you can determine the balance to within a few hundred satoshis.

Path Probing

Path probing explores which routes exist between nodes. Rather than targeting specific channel balances, the attacker maps connectivity and discovers viable payment paths.

This technique helps identify private channels. While private channels are not announced to the network, they still respond to routed payments. By probing various paths, an attacker can discover channels that exist but were never publicly announced.

Path probing also reveals network topology changes in real time. Channel openings, closures, and policy updates can be detected through systematic probing faster than waiting for gossip propagation.

Timing Probing

Timing attacks measure how long payment attempts take to fail. Different failure modes have different latencies: a local failure returns instantly, while a failure five hops away takes longer due to round-trip delays.

By correlating timing data with route information, attackers can sometimes determine which node along a path rejected the payment, even when the error message is encrypted or anonymized.

Privacy Implications

Probing poses significant privacy risks to Lightning Network users:

Transaction Surveillance

By continuously probing channels, an attacker can detect when balances change. A sudden shift in a channel's balance indicates a payment was routed through it. With enough coverage, adversaries can track payments as they flow through the network.

This surveillance is passive and undetectable. The probed nodes see only failed payment attempts, which are common in normal operation. They cannot distinguish malicious probes from legitimate pre-flight checks.

Wealth Exposure

Users with large channel balances become visible targets. Probing reveals not just that a channel exists, but exactly how much value it holds. This information could inform targeted attacks or social engineering.

Payment Correlation

If an attacker probes channels before and after a known payment, they can trace its path by finding which balances changed. Combined with timing data, this enables transaction graph analysis similar to on-chain surveillance techniques.

Deanonymization

Merchants with predictable payment patterns become identifiable. If a channel consistently receives payments at certain times or amounts, probing can reveal business activity and revenue estimates.

Defenses Against Probing

Several techniques help protect against probing attacks, though none provide complete protection:

Shadow Routing

Shadow routing adds extra hops to payment paths that are not strictly necessary. The payment takes a longer route than required, obscuring which channels actually process value. Probers see activity on shadow hops but cannot determine which balances actually changed.

Payment Splitting

Multi-path payments (MPP) split large payments across multiple routes. Instead of one 100,000 sat payment through a single path, ten 10,000 sat payments traverse different channels. This makes balance changes harder to detect and correlate.

Error Message Standardization

Some implementations return generic error messages regardless of the actual failure reason. Instead of revealing "insufficient balance at hop 3," they report "temporary failure." This reduces information leakage but also makes legitimate debugging harder.

Rate Limiting

Nodes can limit how many failed payments they process from any single source. This slows down systematic probing without affecting normal users who rarely generate many consecutive failures.

Random Delays

Adding random delays to error responses defeats timing analysis. If all errors take 100-500ms regardless of where they originated, timing data becomes useless for determining failure location.

Private Channels

Using unannounced channels with trusted partners limits exposure. Private channels do not appear in the public graph, so attackers must discover them through other means before they can be probed. Alternative protocols like Spark avoid channel-based routing entirely, eliminating probing as an attack vector.

Technical Details

Understanding the protocol-level mechanics helps explain why probing works and what constraints limit it:

HTLC Failure Codes

Lightning defines specific failure codes in BOLT 4. Relevant codes for probing include:

• temporary_channel_failure: The channel cannot forward the payment right now, often due to insufficient balance
• amount_below_minimum: Payment is smaller than the channel's HTLC minimum
• fee_insufficient: The fees included do not meet the channel's requirements
• incorrect_or_unknown_payment_details: Reached destination but preimage unknown (expected for probes)

The distinction between temporary_channel_failure (balance issue) andincorrect_or_unknown_payment_details (reached destination) is what makes binary search probing possible.

Onion Routing Limitations

Lightning uses onion routing to encrypt payment paths. Each hop only knows the previous and next nodes, not the full path. However, failure messages travel back through the same onion, and the sender can determine which hop generated the error based on the message structure.

Probe Cost Analysis

Probing is nearly free. Failed payments do not pay routing fees since no value transfers. The only costs are:

• Bandwidth for sending and receiving onion packets
• Computation for cryptographic operations
• Time waiting for responses

A well-connected node can probe the entire public network in hours, updating its view of global liquidity distribution at minimal cost.