Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstalliTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Lightning payment is a treasure hunt through a network of payment channels. Your wallet searches for a path with enough usable, directional liquidity, wraps instructions for each hop in an onion packet, and links every conditional transfer to one secret. The recipient’s revelation of that secret settles the whole path; if it is never revealed, timelocks let the transfers unwind.
The complete journey in one payment
Lightning moves value through a graph of channels rather than asking the Bitcoin blockchain to record every payment immediately. A sender may have no direct channel to a recipient. Instead, several forwarding nodes can relay the payment, each adding a conditional claim called a hash time-locked contract (HTLC).
Every HTLC on the route uses the same payment hash and a different amount and expiry. The recipient knows the matching secret preimage. Revealing that preimage lets the recipient claim the incoming HTLC and gives each upstream forwarding node the proof needed to claim its own incoming HTLC. Without the preimage, the time limits expire in the opposite direction and funds return to the party that offered them. This is the mechanism behind Lightning Labs’ description of payments as atomic: they arrive in full or do not leave the sender’s accounts.
Recommended Free Tools
1. The recipient creates an invoice and a secret
Random secret, public hash
Before the sender searches for a route, the recipient creates a random secret, conventionally written as R. The recipient hashes it to produce H. The invoice or payment request gives the sender the payment details, including the hash, but not R itself.
#1 Best Overall
- BITCOIN EXCLUSIVE, PHONE VERIFICATION: Bitkey is designed from the ground up exclusively for bitcoin — a dedicated hardware wallet for secure bitcoin storage. Approve transactions with a tap using your phone and NFC. No device screen is required.
- SELF-CUSTODY, NO EXCHANGE OR CUSTODIAN REQUIRED: You hold two of the three keys in the Bitkey system – one on your phone and one on your Bitkey device. The third is stored on Bitkey’s server and cannot move your bitcoin on its own.
- NO SEED PHRASE: Set up and use Bitkey without creating or storing a seed phrase.
- 2-of-3 MULTISIG: Three keys are stored separately across your phone, Bitkey device, and Bitkey’s server. Any two keys are required to move your bitcoin.
- BUILT-IN RECOVERY: Encrypted backup and recovery tools can help you regain access if you lose your phone or Bitkey device. You can also designate a Recovery Contact.
The hash is safe to share because it does not reveal the preimage in practical use. The recipient keeps R until a payment arrives. A sender can therefore construct a route and offer conditional transfers without being able to take the money at the end of the route.
What the invoice contributes
The invoice tells the sender which node should receive the payment and supplies the data needed to create the route and HTLC conditions. Depending on the invoice format and wallet, it can also carry an amount, a description, expiry information, and routing hints. Those details affect how a wallet chooses a route, but the hash-and-preimage relationship is what makes the transfers conditional.
2. The sender hunts for a usable route
A graph, not a list of account balances
Lightning nodes learn about announced channels, their endpoints, policies, fees, and timelock requirements. The sender turns that information into a graph and looks for a path from its own node to the recipient. LND documents this as a modified Dijkstra shortest-path problem: a candidate is scored using the amount that must be sent, each hop’s fee, and the additional timelock imposed by the route.
The graph does not reveal the exact balance available in each direction. A channel can advertise substantial total capacity while having little or no spendable liquidity from the sender’s side toward the recipient. This distinction is the central reason a route that looks valid can still fail. Lightning Labs’ sending guide identifies lack of knowledge about node balances as the primary reason payments fail.
Rank #2
- Unparalleled Security: Protect your assets NDA-free EAL 6+ Secure Element, offering robust defense and complete transparency
- Simple & Secure Interface: Manage your digital assets easily with a clear OLED screen for secure on-device confirmations
- Supports 1000s of Coins & Tokens: Securely handle thousands of assets, including Bitcoin, Ethereum, and more, all in one wallet
- Effortless Asset Management: Monitor and transact seamlessly with Trezor Suite, our intuitive desktop and mobile app
- Enhanced Backup Solution: Rest assured with Multi-share Backup, eliminating single points of failure for secure cold wallet recovery
What the route calculation must satisfy
- Directional liquidity: every hop must be able to forward the required amount in the required direction, including the amount needed to pay downstream fees.
- Fee policy: each forwarding node may charge a base fee, a proportional fee, or both. The sender must include those costs when calculating upstream amounts.
- Timelock policy: downstream HTLCs expire sooner than upstream HTLCs, giving each forwarding node time to claim after its downstream payment succeeds.
- Channel and peer state: a peer may be offline, a channel may be disabled, or an announced policy may no longer match the node’s current rules.
- Recipient constraints: the destination and invoice can restrict which routes are acceptable, especially when the recipient provides routing hints for private channels.
A wallet can rank several paths rather than trusting a single shortest route. A low-fee path is not automatically the best path if its liquidity estimate is weak or its peers are unreliable.
3. The sender builds an onion packet
One packet, one view per hop
After selecting a route, the origin node constructs the forwarding instructions specified by BOLT #4. It derives a shared secret for each hop using elliptic-curve Diffie–Hellman (ECDH), then encrypts the packet in layers. The first forwarding node removes the layer intended for it, learns the next peer and the instructions it must apply, and passes the remaining packet onward.
Each intermediary can verify that the packet has not been altered and can learn which node it should contact next. It cannot normally see the complete route, the sender’s entire plan, or the instructions meant for later hops. Re-keying and re-obfuscating at every hop create the “onion” effect: the packet is peeled one layer at a time.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteWhat onion routing does not guarantee
Onion routing limits the information available to an individual forwarding node; it does not make Lightning traffic perfectly anonymous. BOLT #4 explicitly notes that packet association can still be possible through traffic analysis. An observer that can watch timing, sizes, or entry and exit behavior may correlate events even when packet contents are encrypted. Privacy therefore depends on the route, the observers, wallet behavior, and the network information available to an attacker.
Rank #3
- Unparalleled Security: Protect your assets with EAL 6+ Secure Element, offering robust defense and complete transparency
- Simple & Secure Interface: Manage your digital assets easily with a clear OLED screen for secure on-device confirmations
- Supports 1000s of Coins & Tokens: Securely handle thousands of assets, including Bitcoin, Ethereum, and more, all in one wallet
- Effortless Asset Management: Monitor and transact seamlessly with Trezor Suite, our intuitive desktop and mobile app
- Enhanced Backup Solution: Multi-share Backup eliminates single points of failure for secure cold wallet recovery
4. Every hop forwards an HTLC
The same hash, different amounts and deadlines
The sender offers the first hop an HTLC keyed to H. That hop offers a corresponding HTLC to the next hop, and so on, with the same payment hash. Amounts decrease along the route because forwarding fees are deducted. Expiries are staggered: the final hop’s contract expires first, and each earlier hop’s expiry is later.
A forwarding node is not given unrestricted custody of the principal. It is forwarding a conditional claim controlled by a cryptographic script and a time limit. It can settle the claim by presenting the correct preimage after its downstream counterparty has revealed it, or it can recover according to the timeout path if the condition is never met.
Why the staggered timelocks matter
Suppose a downstream node reveals the preimage to its counterparty. The upstream node must have enough remaining time to use that same preimage before its own HTLC expires. The expiry differences provide that safety margin. If all deadlines were identical, a node could learn the preimage too late to claim its incoming amount.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
5. The recipient reveals the preimage and settlement travels backward
Successful settlement
When the final HTLC reaches the recipient, the recipient presents R, which hashes to the invoice’s H. The downstream forwarding node verifies the hash and uses the preimage to claim its incoming HTLC. That node’s upstream counterparty can then do the same. The revelation propagates backward hop by hop until the sender’s first channel settles.
Rank #4
- Dual-chip architecture for maximum protection: The next-gen, fully auditable TROPIC01 chip works alongside a certified EAL6+ Secure Element—completely NDA-free—to deliver radically transparent, industry-leading defense against physical attacks.
- Quantum-ready security: Get protection against future threats with the first-ever hardware wallet designed with quantum-ready architecture.
- See every detail with confidence: Our largest high-resolution color touchscreen makes it easy to navigate your assets, review transactions and manage your coins with clarity.
- Wireless freedom with encrypted Bluetooth control: Manage, buy, swap and stake securely using Trezor Suite on desktop or mobile. Qi2-compatible wireless charging keeps your Trezor powered up. No cables required—security meets convenience.
- Works seamlessly with Android, iOS and desktop: Connect wirelessly or via USB-C to your phone or computer. Manage your crypto anywhere with our companion Trezor Suite app.
Most of these state updates occur off-chain. Channel balances change according to the signed commitment and settlement messages exchanged by the peers; the Bitcoin blockchain does not need to record each successful hop.
If the recipient never reveals it
A recipient may be offline, an intermediary may stop forwarding, or a route may fail before the final HTLC is accepted. In that case, no participant can satisfy the hash condition. Once the relevant timelocks expire, the timeout path restores the conditional funds to the side that offered them. The process can take time because each upstream expiry is deliberately later than the downstream one.
On-chain transactions are the fallback when a peer is unresponsive or a channel must be resolved publicly. They provide timeout and settlement paths, but they are slower, consume blockchain fees, and expose more information than a normal off-chain update.
Why a payment can fail even when the route looked available
| Failure cause | What the sender sees | Why the graph was misleading |
|---|---|---|
| Insufficient directional liquidity | A route failure at a particular channel or hop | Advertised channel capacity described the total channel, not the spendable balance in the required direction. |
| Peer or channel offline | The forwarding attempt times out or is rejected | Public gossip can lag behind the peer’s current connection or channel state. |
| Fee-policy mismatch | The next hop rejects the amount or the route exceeds the sender’s fee limit | Policies may have changed or the sender’s estimate may not include every downstream fee. |
| Timelock-policy mismatch | A hop rejects the proposed expiry or the route cannot satisfy the sender’s limits | Each implementation can enforce minimum or maximum delays that the initial path estimate did not meet. |
| Invoice or destination constraints | The payment is rejected despite apparently healthy channels | The recipient may require a specific path characteristic, use a private channel, or have an expired request. |
A failed attempt does not prove that the recipient is unreachable. It proves only that the selected route could not complete under the conditions known at that moment. The sender can exclude the failing channel, update its view, and try another route. Repeated failures can indicate that the amount is larger than the available liquidity in the relevant direction, not that the network has no path at all.
Best Value
- Effortlessly build your crypto portfolio via the all in one Ledger Wallet app: buy, sell, send, receive, swap, stake and more across popular blockchains. 15,000+ coins & tokens in a single dashboard. Keep a close eye on the market. Compare service providers. Track performance. Get timely alerts. Build your portfolio with confidence.
- Enjoy Bluetooth connectivity, iOS access, and hours of battery use with this mobile-first, secure backup signer. Freedom you can depend on.
- Genuine Check: confirm your signer is authentic during setup with the Ledger Wallet app.
- Protect your signer: keep it in mint condition at all times with a bespoke Pod or Case to avoid scratches and everyday wear and tear.
Can an intermediate node steal the sats?
Not by simply forwarding the HTLC. The node does not know R until a downstream party reveals it, and the hash condition prevents it from claiming the incoming amount with an arbitrary value. Once the preimage is revealed, the node can claim its incoming HTLC, but that claim is matched to the amount and conditions it accepted.
The cryptographic and time-limited script is designed so a routing node operates without custody of third-party funds. A node can still create operational problems: it can refuse to forward, go offline, or cause a timeout delay. Those behaviors produce a failed or delayed payment rather than a license to take the principal. Wallets mitigate them by using route selection, failure feedback, and alternative attempts.
What happens on-chain when cooperation breaks down?
Channel participants normally exchange signed updates off-chain. If one side disappears, the other can publish a commitment transaction and use the applicable timeout or preimage path. The exact transaction sequence depends on the channel implementation and the state being enforced, but the design goal is consistent: a valid preimage permits settlement before the deadline, while an expired deadline permits recovery.
Free tools Windows power users keep installed
One-click scans. No signup required.
Publishing on-chain is therefore a safety valve, not the ordinary path for a successful payment. It can require waiting through timelocks and paying mining fees. Keeping a node online, monitoring its channels, and retaining the data needed to enforce the latest state are practical parts of operating Lightning infrastructure.
How to troubleshoot a failed Lightning payment
- Check the invoice first. Confirm that it has not expired, that the amount is correct, and that you are paying the intended destination. Generate a fresh invoice when the recipient requests one.
- Reduce avoidable route pressure. If your wallet permits it, try a smaller amount or split a large payment. A route that cannot carry the full amount may still carry smaller parts, although multipart behavior depends on the wallet and recipient.
- Retry with a new path. Let the wallet refresh channel announcements and avoid the channel or peer reported in the failure. Repeating the identical route rarely fixes a liquidity or outage problem.
- Review fees and limits. Check the wallet’s maximum fee, maximum routing delay, and any setting that restricts private or unannounced channels. A strict limit can reject a route that would otherwise settle.
- Ask the recipient for a current invoice. The recipient may have closed a channel, gone offline, or issued a request whose expiry has passed.
- Escalate persistent failures with evidence. Record the failure code, the failing channel or hop if the wallet exposes it, the amount, and the time. Those details help an operator distinguish liquidity exhaustion from a policy or connectivity problem.
How to compare Lightning implementations or payment attempts
Different node software and wallets can make different choices without changing the underlying hash-and-timelock design. Use the following axes when evaluating a payment experience or implementation:
| Comparison axis | Questions to ask | Why it matters |
|---|---|---|
| Route finding | Does it use a modified shortest-path search, maintain route history, and consider alternatives? | Better path scoring and failure feedback can reduce attempts that look good on paper but lack liquidity. |
| Fee and timelock policy | How are forwarding fees calculated, and what minimum or maximum delays are accepted? | These values determine the amount the sender must fund and whether a route can be safely timed. |
| Liquidity visibility and management | How does the system estimate directional liquidity, rebalance channels, or react to failed probes? | Total channel capacity alone cannot predict whether a payment will pass. |
| Privacy boundary | Which route details does each hop receive, and what metadata could an observer correlate? | Onion encryption hides the full route from intermediaries but does not defeat all traffic analysis. |
| Failure and retry behavior | Can the sender identify a failing hop, exclude it, refresh gossip, and select another route? | Fast, informative retries turn transient failures into a better chance of completion. |
| Settlement location | Does the normal path remain off-chain, and what happens when a peer is unresponsive? | Off-chain settlement is efficient; on-chain timeout and settlement paths provide recovery at higher cost and delay. |
The practical mental model
- The invoice supplies the destination and hash. The recipient keeps the preimage until payment is ready to settle.
- The sender is solving a constrained graph problem. Fees, expiries, peer status, and directional liquidity all matter.
- The onion packet limits each hop’s knowledge. A hop learns its next destination, not the entire route.
- HTLCs synchronize the money. One hash-linked secret coordinates every conditional transfer.
- Liquidity is directional and changes over time. A public channel announcement is not a guarantee that the needed amount can move now.
- Failure is recoverable by design. Alternative routes, timeout refunds, and on-chain enforcement prevent an incomplete payment from becoming an uncontrolled transfer.
Protocol details in BOLT #4 and Lightning documentation were checked on October 14, 2026; individual implementations can revise routing policies and operational behavior. The enduring design is the combination of route discovery, layered forwarding instructions, and a shared preimage condition: a payment either completes across the route or the conditional transfers expire without giving an intermediary the principal.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
