Bitcoin on-chain settles roughly every 10 minutes and costs tens of cents to dollars per transaction. That's fine for periodic settlement but unusable for buying coffee or paying a paid API call. The Lightning Network solves this by moving most transactions off-chain into a network of payment channels.
What a channel actually is
Two parties (you and a counterparty, typically a routing node) jointly fund a multi-sig Bitcoin output with some BTC. Now they have an on-chain anchor — but inside the channel, they can exchange signed balance updates instantly and for free. Each update is a new "state" of the channel. The on-chain anchor only matters when:
- A new channel is opened (one on-chain tx)
- A channel is closed (one on-chain tx)
- A counterparty cheats and broadcasts an old state (the channel close becomes adversarial)
For day-to-day Lightning use, you never see the on-chain layer. Payments flow through paths of channels (your node → routing node A → routing node B → recipient's node) using HTLCs — Hashed Time-Locked Contracts — so each hop only sees the previous and next nodes.
Custody — the unavoidable trade-off
Lightning balance is in channels you co-own with counterparties. Three custody profiles exist:
| Mode | Who holds the keys | Trust |
|---|---|---|
| Self-custodial node | You run LND / Core Lightning / Eclair | Trust nobody but the watchtower |
| Managed provider (Gopnik's default) | The provider holds channel keys; you authorise via account auth | Trust the provider not to seize / collude |
| Custodial wallet (Wallet of Satoshi etc.) | The provider fully holds your sats | Trust the provider absolutely |
Gopnik picks the middle: a managed provider (Breez SDK by default in iter-F). This is a deliberate compromise — running a self-custodial node requires watchtowers + channel rebalancing + on-chain fee management, all of which are operational burdens we'd rather not push onto every user. The trade-off is that the provider can theoretically seize your funds. In practice, reputable providers don't (it's a one-shot defection that kills their business).
Discipline: Lightning balance is hot wallet money. Don't park large sums in channels. Settle to on-chain when LN balance exceeds your operational threshold (€500 is a reasonable default).
Finality and reversibility
Lightning payments are final the moment your counterparty's node acknowledges. There's no "wait for confirmations" — the cryptographic protocol of HTLC settlement is the finality.
But: a Lightning payment can still fail. The HTLC has a timeout; if the recipient's node is offline or the path can't route, the payment unwinds and the sender keeps the sats. This is different from on-chain — there's no "stuck transaction" state, just "succeeded" or "failed."
The wallet's UI shows three states:
- Pending: the provider has accepted the pay request but hasn't routed yet
- In-flight: an HTLC is locked across the path
- Settled: the recipient acknowledged; preimage received
Most successful payments transition pending → settled in under a second.
Fees
Lightning fees are denominated in sats per payment, not per kilobyte. They're paid to the routing nodes you traverse. Typical:
| Amount | Typical fee |
|---|---|
| 1,000 sats (~€1) | 0-3 sats |
| 100,000 sats (~€100) | 5-30 sats |
| 1,000,000 sats (~€1,000) | 100-1,000 sats |
The fee is bounded by max_fee_sats in the pay request. The wallet defaults to a sensible cap; you can override per-payment for high-priority routes.
What you commit to
- Lightning balance lives in channels managed by Gopnik's provider
- Settle large balances to on-chain rather than holding in LN long-term
- Failed LN payments leave your sats intact; there's no stuck-tx footgun
- Max-fee caps protect against runaway routing costs
The next lesson covers the one operational risk Lightning users absolutely must understand: watchtowers and the channel-force-close scenario.