How Do Lightning Payments Work?

By Blockstream Engineering · Last updated June 2026

The Anatomy of a Lightning Payment

A Lightning payment looks simple from the outside: scan a QR code, confirm the amount, and see a success screen within seconds. Under the surface, a precise sequence of cryptographic operations takes place across multiple nodes in the network.

Here is what happens step by step when you make a Lightning payment:

1. The receiver generates an invoice. The receiver's Lightning node creates a random 256-bit number called a preimage, then hashes it using SHA-256 to produce a payment hash. The node encodes this hash, along with the amount, an expiry time, and routing hints, into a BOLT11 invoice (typically displayed as a QR code or a string starting with lnbc).
2. The sender's wallet decodes the invoice. Your wallet reads the invoice, extracts the payment hash, the amount, the destination node's public key, and any routing hints.
3. The sender's node finds a route. Using its local view of the Lightning Network's channel graph, your node calculates a path from itself to the receiver. This path may pass through one or more intermediate routing nodes. Each hop along the route has a channel with sufficient liquidity to forward the payment.
4. The sender constructs onion-routed instructions. Your node wraps the routing instructions in layers of encryption, one layer per hop. Each intermediary can only decrypt its own layer, learning just enough to forward the payment to the next node. No intermediary sees the full route.
5. HTLCs lock the funds at each hop. Starting from the sender, each node along the route creates an HTLC. The HTLC says: "I will pay you X sats if you can produce the preimage that hashes to this payment hash, and you must do so before this timelock expires". The funds are locked, not transferred, at each hop.
6. The receiver reveals the preimage. When the HTLC reaches the receiver, the receiver is the only party who knows the preimage. The receiver reveals it to claim the payment from the last hop.
7. The preimage propagates back. Each intermediary uses the preimage to claim its incoming HTLC. The preimage cascades back hop by hop until the sender's node receives it, confirming that the payment reached the intended recipient.
8. Channel balances update. At each hop, the commitment transactions (the off-chain records of who owns what in the channel) update to reflect the new balances. No on-chain transaction occurs.
9. The sender receives cryptographic proof of payment. The preimage itself is an unforgeable receipt. Only the intended receiver could have produced it, and the sender can verify it by hashing it and comparing the result to the original payment hash.

The entire process, from scanning the invoice to receiving proof of payment, typically completes in under three seconds. For a payment routed through two or three intermediaries, it often takes less than a second.

Payment Channels in Depth

Every Lightning payment travels through one or more payment channels. A payment channel is a two-party financial relationship anchored to the Bitcoin blockchain. Two nodes open a channel with an on-chain transaction, exchange off-chain updates as they route payments, and eventually close the channel with another on-chain transaction. Everything between the open and the close happens off-chain.

Opening a Channel

Opening a payment channel requires a single on-chain Bitcoin transaction called the funding transaction. The channel establishment flow is defined in BOLT 2, which specifies the message exchange between peers: open_channel, accept_channel, funding_created, and funding_signed. This transaction sends bitcoin into a 2-of-2 multisig address controlled by both channel partners. Neither party can unilaterally move the funds; both must sign any transaction that spends from this address.

The funding transaction is a standard Bitcoin transaction. It appears on the blockchain, pays a mining fee, and requires the usual confirmation time. Once confirmed, the channel is open.

Typically, one party provides the initial funding (though dual-funded channels, where both parties contribute, are increasingly supported). The initial channel state reflects whoever put in the bitcoin: if Alice funds the channel with 500,000 sats, the opening balance is 500,000 sats on Alice's side and zero on Bob's side.

Channel Balance and Commitment Transactions

The balance of a channel shifts with every payment routed through it. If Alice starts with 500,000 sats and pays Bob 50,000, the new balance is 450,000 on Alice's side and 50,000 on Bob's side. These balance updates happen entirely off-chain through a mechanism called commitment transactions.

A commitment transaction is a pre-signed Bitcoin transaction that could, if broadcast, close the channel and distribute the funds according to the current balance. Both parties hold their own version of the commitment transaction at all times. The structure of each commitment transaction is defined in BOLT 3, which specifies the exact output types: a to_local output (spendable by the holder after a delay, or immediately by the counterparty using a revocation key), a to_remote output (spendable immediately by the other party), and any pending HTLC outputs. Each time the balance changes, both parties sign a new commitment transaction reflecting the updated state and revoke the old one.

The revocation mechanism is critical. When a new state is created, each party provides the other with a revocation key for the old state. If either party later tries to broadcast a revoked commitment transaction (an old state that gives them more bitcoin than they currently have), the other party can use the revocation key to claim all the funds in the channel as a penalty. This economic punishment is what keeps both sides honest.

Closing a Channel

Channels can close in two ways:

Cooperative close. Both parties agree to close the channel. They sign a single closing transaction that distributes the funds according to the final balance and broadcasts it to the Bitcoin blockchain. This is the cleanest and cheapest option: one on-chain transaction, standard fees, and both parties get their bitcoin immediately after confirmation.

Force close. If one party is unresponsive or uncooperative, the other party can unilaterally broadcast their latest commitment transaction. Force closing works, but it is slower and more expensive. The party that initiates the force close must wait through a timelock period set by the to_self_delay parameter (negotiated during channel opening per BOLT 2, typically 144 blocks or about one day) before they can spend their to_local output. This delay gives the counterparty time to check whether the broadcast commitment transaction is the latest state, and to submit a penalty transaction if it is not. The penalty transaction, as specified in BOLT 3, uses the revocation key to sweep the cheater's to_local output, claiming the entire channel balance.

In practice, most channel closures are cooperative. Force closes are a safety mechanism, not a common occurrence.

Under the Hood: Commitment Transaction Structure

Each commitment transaction, as defined in BOLT 3, contains up to three types of outputs. The to_local output pays the transaction holder but enforces a spending delay (the to_self_delay negotiated per BOLT 2), giving the counterparty time to submit a penalty if the state is revoked. The to_remote output pays the counterparty immediately with no delay. Any in-flight payments appear as separate HTLC outputs, each with a script that allows claiming via preimage reveal (hash lock) or timeout refund (time lock).

Both parties hold asymmetric versions of each commitment transaction. Alice's version pays her through a delayed to_local output and pays Bob immediately through to_remote. Bob's version does the reverse. This asymmetry is what makes the penalty mechanism work: the broadcaster always faces a delay on their own funds, giving the counterparty time to act if the state is revoked. The revocation keys are derived using a per-commitment point scheme, where each new state generates a new point and both parties exchange the previous state's revocation secret.

When channels have pending HTLCs, the commitment transaction grows to include offered HTLC outputs (payments you are forwarding) and received HTLC outputs (payments you are receiving). Each HTLC output has its own timeout and preimage clause, and if broadcast on-chain, resolves through a second-stage HTLC-success or HTLC-timeout transaction. This two-stage settlement ensures that the HTLC resolution does not interfere with the main channel settlement.

Invoices and Payment Requests

Before a Lightning payment can happen, the receiver must communicate what they want to be paid. On the Lightning Network, this typically happens through an invoice.

BOLT11 Invoices

The standard Lightning invoice format is defined in BOLT11 (the Lightning specification uses "BOLT" for its protocol documents, short for Basis of Lightning Technology). A BOLT11 invoice is a string of characters, usually rendered as a QR code, that encodes everything the sender needs to complete a payment.

A BOLT11 invoice contains:

All of this is encoded in a compact format: a human-readable prefix (lnbc for mainnet), the amount, and a bech32-encoded data section.

Payment Hash and Preimage

The payment hash and preimage form the cryptographic backbone of every Lightning payment. The receiver generates a random preimage, hashes it, and includes the hash in the invoice. The entire payment process, from HTLC creation to final settlement, is a relay race to deliver the preimage from receiver to sender.

The preimage is the proof of payment. If you hold a preimage that hashes to a specific payment hash, you can prove that the payment was completed. No one can forge this proof without breaking SHA-256.

Invoice Expiry

Invoices have expiration times for good reason. When a receiver creates an invoice, their node must store the preimage and monitor for incoming HTLCs. If invoices never expired, nodes would accumulate state indefinitely for payments that may never arrive.

More importantly, the receiver's channel state could change between invoice creation and payment arrival. The routing hints in the invoice might become stale, channel balances might shift, and the paths suggested might no longer have sufficient liquidity. Expiry times (commonly one hour, but configurable) limit this window of staleness.

Keysend and Spontaneous Payments

Standard Lightning payments require the receiver to create an invoice first. Keysend removes this requirement. With keysend, the sender generates the preimage themselves and includes it (encrypted) in the onion-routed payment data. The receiver's node extracts the preimage when the payment arrives and uses it to settle the HTLCs.

Keysend is useful for tips, donations, and any situation where the sender wants to push a payment without first requesting an invoice. The tradeoff is that keysend payments lack the receiver-generated proof of payment that comes with standard invoices, since the sender created the preimage themselves.

Routing: How Payments Find a Path

Most Lightning payments do not travel through a direct channel between sender and receiver. They are routed through a series of intermediary nodes, each forwarding the payment one hop closer to the destination. This multi-hop routing is what makes the Lightning Network a network rather than a collection of isolated channels.

Multi-Hop Payments

Consider a payment from Alice to Dave. Alice does not have a direct channel with Dave, but she has a channel with Bob, Bob has a channel with Carol, and Carol has a channel with Dave. The payment flows: Alice → Bob → Carol → Dave.

At no point does Alice send bitcoin directly to Dave. Instead, Alice pays Bob (through their shared channel), Bob pays Carol (through their shared channel), and Carol pays Dave (through their shared channel). The channel balances update at each hop. The result: Alice has less bitcoin, Dave has more, and Bob and Carol's net balances are unchanged (though the distribution across their channels shifts).

The sender is responsible for finding the route. Lightning nodes maintain a local map of the network's public channels (the channel graph) and use pathfinding algorithms to calculate viable routes based on channel capacities, fee policies, and reliability.

Hash Time-Locked Contracts (HTLCs)

Multi-hop routing only works if every intermediary is incentivized to play honestly and no intermediary can steal funds in transit. Hash Time-Locked Contracts are the mechanism that makes this possible.

An HTLC is a conditional payment with two clauses:

• Hash lock: The payment can be claimed by anyone who presents the preimage that hashes to the specified payment hash.
• Time lock: If the preimage is not presented before a deadline, the funds return to the sender.

These two conditions, used together, make trustless multi-hop routing work. Here is why:

1. Alice creates an HTLC with Bob: "I'll pay you 100,050 sats if you can present the preimage within 40 blocks".
2. Bob creates an HTLC with Carol: "I'll pay you 100,025 sats if you can present the preimage within 30 blocks".
3. Carol creates an HTLC with Dave: "I'll pay you 100,000 sats if you can present the preimage within 20 blocks".
4. Dave knows the preimage (he created the invoice). He reveals it to Carol and claims 100,000 sats.
5. Carol now knows the preimage. She reveals it to Bob and claims 100,025 sats.
6. Bob reveals the preimage to Alice and claims 100,050 sats.

Each intermediary's timelock is shorter than the previous one. This ensures that each node has time to claim its incoming HTLC after revealing the preimage on its outgoing HTLC. If any hop fails (a node goes offline, for example), the timelocks expire and the funds return to their original owners.

No intermediary can steal the payment because they cannot claim the incoming HTLC without the preimage, and they cannot obtain the preimage without forwarding the payment downstream. The cryptographic structure of HTLCs makes theft unprofitable at every step.

Onion Routing: Privacy Through Layered Encryption

Lightning uses onion routing as defined in BOLT 4 (based on the Sphinx packet format) to protect the privacy of both sender and receiver. When the sender constructs the payment route, they wrap the routing instructions in concentric layers of encryption, one layer per hop. Each node decrypts only its own layer, which reveals the next hop and the forwarding instructions, but nothing else. The onion packet has a fixed size of 1,366 bytes, including a 1,300-byte routing-information field, regardless of the number of hops (up to a maximum of 20), preventing intermediaries from inferring their position in the route based on packet size.

The result:

• The sender knows the full route but reveals it to no one.
• Each intermediary knows only who sent it the payment and who to forward it to. It does not know whether the previous node was the original sender or another intermediary. It does not know whether the next node is the final receiver or another intermediary.
• The receiver knows the payment arrived but does not know the full route it traveled.

This design means that even if a routing node is monitoring traffic, it cannot determine the origin or final destination of a payment with certainty. Core Lightning (CLN), maintained by Blockstream, is one of the major Lightning implementations and supports onion routing, multi-part payments, and keysend by default.

Routing Fees

Routing nodes charge small fees for forwarding payments. Each node advertises its fee policy on the network, consisting of two components:

• Base fee: A fixed fee per forwarded payment (e.g., 1 sat).
• Proportional fee (fee rate): A percentage of the forwarded amount (e.g., 0.001%, expressed in millionths as the fee_rate).

When the sender calculates a route, it factors in the cumulative fees across all hops and includes them in the initial HTLC amount. The fees are peeled off at each hop: each intermediary keeps its fee and forwards the remainder.

In the example above, Alice sent 100,050 sats for a 100,000-sat payment. Bob kept 25 sats, Carol kept 25 sats, and Dave received the full 100,000. The sender always knows the exact total cost before initiating the payment.

Fees on Lightning

Lightning fees are dramatically lower than on-chain Bitcoin transaction fees. An on-chain transaction might cost anywhere from a few hundred sats to tens of thousands of sats depending on mempool congestion. A Lightning payment of the same amount typically costs a few sats total, often less than one sat for smaller payments.

How Fees Are Structured

Every routing node independently sets its fee policy:

Total fee for a routed payment = sum of (base fee + proportional fee) at each hop along the route.

For a 100,000-sat (~$100 at typical prices) payment routed through three hops, a typical total fee might be 3 to 10 sats (fractions of a cent). Compare this to an on-chain transaction fee of 2,000 to 20,000+ sats for the same transfer.

How Routing Nodes Set Fees

Routing node operators set fees based on several factors: the cost of their channel capital (bitcoin locked in channels earns no yield elsewhere), the demand for routing through their channels, and competitive pressure from other routes. Some operators run routing nodes as a business, optimizing fees to maximize routing volume. Others run them at low or zero fees to support the network.

Fee competition works in users' favor. If a node sets its fees too high, pathfinding algorithms will route around it. If a node sets fees too low, it may not recover the on-chain costs of opening and maintaining its channels. The market finds a balance.

Speed and Finality

Speed is one of Lightning's most visible advantages. Payments settle in seconds, sometimes in under 500 milliseconds for well-connected nodes. But "settlement" on Lightning means something different than on the base layer.

Lightning Settlement Speed

A Lightning payment completes when the preimage propagates back to the sender. At that point, the sender has cryptographic proof that the receiver was paid, and all channel balances along the route have been updated. The entire round trip, from HTLC creation to preimage return, typically takes one to three seconds.

This speed comes from the payment traveling across direct network connections between nodes, not waiting for a block to be mined. There is no proof-of-work, no block interval, and no confirmation delay. Each hop is a direct message between two connected peers.

Finality: Lightning vs. Base Layer

On-chain Bitcoin transactions achieve probabilistic finality through accumulated proof-of-work. One confirmation (one block, ~ten minutes) is sufficient for small payments. Six confirmations (~one hour) is the traditional threshold for high-value transfers. Each additional block makes reversal exponentially more difficult.

Lightning settlement is different. When the preimage arrives back at the sender, the payment is conditionally final: it is final as long as the current channel states are respected. The underlying security comes from the Bitcoin base layer. Either party in a channel can broadcast their commitment transaction to the blockchain at any time, converting the off-chain balance into an on-chain settlement. The bitcoin never leaves the Bitcoin security model; it is simply managed off-chain until one party decides to settle on-chain.

For everyday payments, Lightning's instant settlement and cryptographic proof of payment provide strong enough finality. For large transfers where base-layer settlement is preferred, an on-chain transaction remains the appropriate choice.

Channel Management

Payment channels need active management to function well. The two most important resources to manage are inbound liquidity and outbound liquidity, and the balance between them determines what your node can do.

Inbound vs. Outbound Liquidity

Outbound liquidity is the bitcoin on your side of a channel. It is the maximum amount you can send through that channel.

Inbound liquidity is the bitcoin on the remote side of a channel. It is the maximum amount you can receive through that channel.

The total capacity of a channel is fixed at the amount locked in the funding transaction. As you send payments, your outbound liquidity decreases and your inbound liquidity increases. As you receive payments, the reverse happens.

The need for inbound liquidity is one of the most common sources of confusion for new Lightning users. If you open a channel with 500,000 sats, you can send up to 500,000 sats but you cannot receive anything through that channel until some bitcoin flows to the other side. To receive payments, you need channels where the remote party has committed bitcoin toward you.

Rebalancing Channels

Over time, channels can become "depleted" in one direction: all the bitcoin ends up on one side, leaving no capacity for payments in the other direction. Rebalancing is the process of redistributing bitcoin across your channels to restore bidirectional capacity.

The most common rebalancing method is a circular payment: your node routes a payment to itself through a path that moves bitcoin from a channel with excess outbound liquidity to a channel that needs it. You pay routing fees for this, but the result is restored capacity across your channels.

Other approaches include submarine swaps (exchanging on-chain bitcoin for Lightning liquidity) and purchasing inbound channels from liquidity providers.

Channel Capacity Limits

Each channel has a maximum capacity set at the time of opening. The BOLT specification allows channels up to approximately 16.8 million sats (~0.168 bitcoin, the legacy pre-wumbo cap of 2^24 - 1 sats), though most channels are much smaller. Modern implementations support "wumbo" channels that lift this cap, allowing much larger channel capacities. A single channel limits both the maximum single payment you can send and the maximum you can receive through that channel.

For larger payments, Multi-Part Payments (covered below) allow splitting across multiple channels, effectively raising the practical limit for any single payment.

Wallets like the Blockstream app make Lightning payments as simple as scanning a QR code, handling the underlying complexity behind the scenes. In the Blockstream app, Lightning payments are delivered through Liquid-Lightning atomic swaps rather than user-managed channels, so there are no channels or liquidity for the user to manage.

Lightning Payment Security

Lightning payments are ultimately secured by the Bitcoin blockchain. The off-chain updates are fast and cheap, but the on-chain settlement layer is always available as the final arbiter. Several mechanisms ensure that cheating is unprofitable and detectable.

Penalty Transactions

The primary enforcement mechanism is the penalty transaction. As described in the payment channels section, each time a channel state updates, both parties revoke the old state by exchanging revocation keys. If either party broadcasts a revoked (outdated) commitment transaction, the other party can use the revocation key to create a penalty transaction that sweeps the entire channel balance.

This means that attempting to cheat by broadcasting an old state is not just unsuccessful; it is economically devastating. The cheater loses not just the disputed amount but all of their funds in the channel. This asymmetric punishment creates a strong incentive to always broadcast the latest state.

Watchtowers

The penalty mechanism only works if the honest party detects the cheating attempt and responds before the timelock expires. This requires monitoring the Bitcoin blockchain for old commitment transactions. If you are offline when your counterparty cheats, you might miss the window to submit the penalty transaction.

Watchtowers solve this problem. A watchtower is a third-party service that monitors the blockchain on your behalf. You provide the watchtower with encrypted breach remedy data for each channel state. If the watchtower detects an old commitment transaction being broadcast, it decrypts and submits the penalty transaction. You do not need to be online. The watchtower cannot access your funds under normal circumstances; it can only act when a specific breach condition is met.

Running or connecting to a watchtower is an important security practice for anyone operating a Lightning node with significant funds, particularly if the node cannot guarantee 100% uptime.

The Security Model

Lightning's security model can be summarized as follows:

• Base-layer security: The bitcoin in a Lightning channel is locked in an on-chain 2-of-2 multisig. It can only be moved with both signatures or through a broadcast commitment transaction that is validated by Bitcoin's consensus rules.
• Economic security: The penalty mechanism makes cheating unprofitable. A rational actor will never broadcast an old state because the expected loss (entire channel balance) exceeds the expected gain (the disputed amount).
• Monitoring requirement: At least one party (or their watchtower) must monitor the blockchain to enforce penalties. This monitoring requirement, along with the need to keep keys online to receive payments, is a key difference between Lightning's security assumptions and a simple on-chain transaction.

The bitcoin in a Lightning channel remains anchored to base-layer settlement, but Lightning adds operational security assumptions, such as blockchain monitoring and keeping keys online to receive, that bitcoin held in cold storage on the base layer does not carry. The base layer provides final settlement, and the Lightning protocol adds an economic incentive layer on top of it.

Multi-Part Payments (MPP)

A fundamental constraint of single-path Lightning payments is that no payment can exceed the capacity of the smallest channel along the route. If one channel in a three-hop path has only 200,000 sats of available liquidity, the maximum payment through that route is 200,000 sats, regardless of how much liquidity exists in the other channels.

Multi-Part Payments (also called multipath payments) eliminate this bottleneck by splitting a single payment into multiple smaller parts, each routed independently through different paths in the network. The receiver collects all parts and only releases the preimage once the full amount has arrived.

For example, a 1,000,000-sat payment might split into four parts of 250,000 sats each, routed through four different paths. No single channel needs to handle the full amount. The receiver's node reassembles the parts atomically: either all parts arrive and the payment succeeds, or none are claimed and the payment fails.

MPP has significant practical benefits:

• Larger effective payments: Payments are no longer limited by the capacity of a single channel or route.
• Higher reliability: If one path fails, only that part needs to be retried. The other parts remain in flight.
• Better network utilization: Spreading payments across multiple paths distributes the load and reduces the chance of depleting any single channel.

MPP is supported by all major Lightning implementations and is used automatically by modern wallets when the payment amount exceeds what a single path can handle.

Practical Considerations

Lightning is production-grade technology used by millions of people, but it comes with tradeoffs that users and node operators should understand.

Online Requirement

In a standard channel setup, your node must be online to receive Lightning payments. Unlike on-chain bitcoin, where you can receive funds to an address whether or not your wallet is running, Lightning payments require the receiver's node to be active and reachable to finalize the HTLC exchange.

For custodial and semi-custodial Lightning wallets, the service provider's node handles this requirement, allowing you to "receive" payments while offline (the service receives on your behalf). For self-custodial node operators, uptime is a real operational requirement.

Emerging approaches, like asynchronous payments and trampoline routing, aim to relax this constraint. But for standard Lightning channels in 2026, the receiver's node needs to be online.

Backup Requirements

On-chain bitcoin can be fully recovered from a recovery phrase (a set of 12 or 24 words). Lightning channel state cannot. Your recovery phrase can restore your on-chain funds, but Lightning channels involve off-chain state (commitment transactions, revocation keys, HTLC data) that exists only on your node.

If you lose your channel state, you lose the ability to enforce the latest channel balance. Your counterparty could close the channel with an older state that gives you less bitcoin (though honest counterparties will close with the correct state).

Static Channel Backups (SCBs) provide a safety net. An SCB stores enough information to reconnect to your channel partners and have them close the channels. In practice the counterparty force-closes with its latest state, and your funds are returned to your on-chain wallet. Most Lightning node implementations support SCBs, and maintaining a current backup is essential for anyone running a Lightning node with meaningful funds.

Running Your Own Node vs. Using a Service

There is a spectrum of approaches to using Lightning:

For most users, a self-custodial wallet like the Blockstream app provides the best balance of security and usability, with Lightning, on-chain Bitcoin, and Liquid all accessible from a single interface. For power users, merchants, and businesses, running a full Lightning node provides maximum control and the ability to earn routing fees. Blockstream's Greenlight offers a middle path: a cloud-hosted Core Lightning node where the operator retains key control on their own device while Greenlight handles infrastructure and uptime. The choice depends on your technical comfort, the amounts involved, and how much operational responsibility you are willing to take on.

Frequently Asked Questions

How much does a Lightning payment cost?

Most Lightning payments cost a few sats total in routing fees, often less than one sat for small payments. The exact fee depends on the route, the number of hops, and each routing node's fee policy. For a typical payment routed through two or three intermediaries, expect to pay fractions of a cent. This is orders of magnitude cheaper than on-chain Bitcoin transaction fees.

How fast are Lightning payments?

Lightning payments typically settle in one to three seconds, with some completing in under 500 milliseconds. The payment travels directly between nodes across network connections rather than waiting for a block to be mined. Compare this to on-chain transactions, which require at least one block confirmation (~ten minutes) and often multiple confirmations for larger amounts.

Is bitcoin on Lightning still secured by the Bitcoin blockchain?

Yes. The bitcoin in a Lightning channel is locked in an on-chain 2-of-2 multisig address. Either party can broadcast a commitment transaction to settle the channel on-chain at any time. The penalty mechanism, specified in BOLT 3, prevents cheating by making it economically devastating to broadcast an old channel state: the counterparty can use the revocation key to sweep the entire channel balance. Lightning adds speed and efficiency on top of Bitcoin's base-layer security without replacing it. The commitment transactions are valid Bitcoin transactions that any Bitcoin full node can verify and include in a block.

What happens if a routing node goes offline during a payment?

If a routing node goes offline mid-payment, the HTLCs at each hop have built-in CLTV (CheckLockTimeVerify) timelocks that decrease at each hop along the route. If the preimage is not delivered before the timelock expires, the HTLC-timeout transaction returns the funds to the sender's side of each channel. No bitcoin is lost. The sender's wallet will typically retry the payment through an alternate route, using updated channel graph data from the BOLT 7 gossip protocol to avoid the unresponsive node.

Do I need to run a Lightning node to use Lightning?

No. Self-custodial wallets like the Blockstream app handle the technical complexity behind a simple interface. In the Blockstream app, Lightning payments are delivered through Liquid-Lightning atomic swaps, so there are no channels or routing for the user to manage. Running your own node gives you maximum control and the ability to earn routing fees, but it requires more technical knowledge, uptime management, and channel liquidity management.

Can someone see my Lightning payments?

Lightning uses onion routing as specified in BOLT 4, which means each node in the payment path only knows its immediate neighbors. The fixed-size onion packet (1,366 bytes) prevents intermediaries from inferring their position in the route. No intermediary can see the full route, the original sender, or the final receiver. The sender knows the full route, but this information is not shared. BOLT12 further improves privacy by introducing blinded paths, which hide the recipient's node identity even from the sender's pathfinding. This provides stronger transaction privacy than standard on-chain Bitcoin transactions, where all inputs, outputs, and amounts are publicly visible on the blockchain.