Lightning Routing means finding and using a path for a payment through the Lightning network. The path consists of payment channels: their participants lock funds together in Bitcoin and update how much belongs to each of them. Programs called nodes manage these channels. The sender usually plans a route using public information, details from the recipient and previous attempts. It cannot see every current balance, however, so it has to estimate whether a path will work and sometimes try another.
Anna wants to pay for coffee but has no channel with the café. She has one with Pavel, who has another with the café. The payment can therefore go through him: a balance shifts from Anna to Pavel in the first channel, and from Pavel to the café in the second. The same coin is not being passed between channels; instead, their balances change in linked steps. Pavel therefore needs usable funds of his own on the side from which he pays the café. The sender’s wallet or node chooses a path to the recipient and prepares instructions for each step. The recipient supplies the necessary details and supported features, possibly including information about a private final segment. Nodes along the way then forward the payment as instructed. They do not each independently find the entire route to the destination. [1] [4]
Gossip is how nodes share information. BOLT #7 describes channel announcements and directional updates: base and proportional fees, the CLTV expiry difference, minimum and maximum amounts, and an availability flag. The advertised terms do not prove that the peer is currently online or has enough funds. Here, CLTV refers to a deadline expressed as a Bitcoin block height, meaning the block’s position in the chain, rather than an exact time on a clock. The gap between deadlines gives an intermediary time to respond if forwarding stalls. [2]
A channel’s total capacity does not reveal how much each side can currently send. The sender knows its own channels; elsewhere it relies on estimates and past successes and failures. Software therefore weighs both fees and success probability. Meanwhile, another payment may change the available liquidity: the funds that can be sent in the required direction. [4] [5]
The steps are linked by HTLCs, which are conditional payments: completing them requires revealing the corresponding secret, while an uncompleted payment can be reclaimed after its deadline. The calculation starts with the recipient’s amount and works backward. Each intermediary needs the amount for the next node plus its own fee. Its incoming HTLC must expire sufficiently later than its outgoing HTLC, according to the required CLTV difference. A longer route can thus increase both costs and the time funds remain tied up if something goes wrong. [1] [2]
Onion routing in BOLT #4 uses the Sphinx construction: each step receives separately encrypted instructions. An intermediary knows its previous and next peer and its own instructions. The packet itself does not reveal the complete route, its length or the intermediary’s exact position. Traffic analysis or cooperation between nodes can nevertheless weaken privacy. [1]
A channel may fail temporarily, the fee may be too low, the CLTV may be wrong or the next peer unavailable or unknown. The sender receives only limited error information. Its software can lower a route’s score, recalculate and try again. This is not a monetary fine paid to a node, and one result is not a permanent reliability rating. [1] [4]
Finding connections is not enough: every step must accept the HTLC and have enough spendable funds in the required direction. Some of the balance may be held as a reserve or tied up in unfinished payments. The technical fields htlc_minimum_msat and htlc_maximum_msat also set the lower and upper amount limits for a single HTLC in that direction. The unit msat is a thousandth of a satoshi; a satoshi is the smallest unit of value on the Bitcoin blockchain. Even a high advertised limit does not prove the necessary liquidity is available now. One unsuitable channel can therefore stop the whole route. [2]
If the recipient supports basic MPP, a payment split into several parts, the sender can divide the total amount, identified in the protocol as total_msat, across several paths. The recipient waits for the necessary parts and settles them together. This can use liquidity spread across channels, but MPP creates no new liquidity. It adds HTLCs, attempts and potentially fees. [1]
Route hints in BOLT #11 can give the sender details of the final unannounced steps. Route blinding, used in BOLT #12, instead provides an encrypted final segment through an entry node, the introduction point. The sender must still find a usable route to that point and meet the aggregate fee and CLTV conditions. Better privacy does not guarantee delivery. [3] [6] [1]
For everyday payments, the wallet handles route finding. The following details are mainly useful to node operators and when investigating repeated problems. Record the software and version, amount, maximum fee and CLTV limit, number of attempts, routes used, completion time and precise failure reason. Compare the same pair of nodes at a similar time. Success describes a particular payment in a particular network state, not a permanent global score. [4] [5]
For the clearest picture, read this entry together with Lightning Network, HTLC, Lightning liquidity, Payment Channel, Bitcoin, Inbound Liquidity. The reverse links also lead from HTLC, Lightning liquidity, BOLT 12, Inbound Liquidity.