Field Notes

entity

Lightning Network

StatusStableReviewdue UpdatedStands on3 sourcesSupportsnotes

The Lightning Network is a payment-channel network for BTC. It moves repeated payments away from Bitcoin L1 while retaining the ability to enforce a channel’s final state on-chain. This can make small interactive payments complete in seconds without placing every intermediate transfer in a Bitcoin block.

Cryptocurrency protocol documentation preserves the official overview used by this note and Cryptocurrency design comparison.

Channels turn settlement into a dispute boundary

Two peers open a channel with an on-chain funding transaction. They then exchange signed commitment states that redistribute the channel’s fixed balance. Only opening, cooperative closing, or dispute transactions need to reach Bitcoin under ordinary operation.

Multi-hop payments use conditional transfers so that every hop succeeds or the route unwinds. The receiver supplies an invoice tied to a secret; HTLCs use the secret and timeouts to make settlement atomic across the route. Intermediate nodes do not need to trust one another with the payment amount.

flowchart TD
  A[Payer channel] --> B[Routing node]
  B --> C[Routing node]
  C --> D[Recipient channel]
  D -->|secret completes every hop| A
  A -. dispute or close .-> E[Bitcoin L1]
  B -. dispute or close .-> E
  C -. dispute or close .-> E
  D -. dispute or close .-> E

Liquidity is directional

A channel balance is not generic network capacity. Funds on one side support outgoing payments from that side; funds on the other side support incoming payments. A route can therefore exist topologically and still fail because one hidden directional balance is too small. Official operator guidance identifies unknown channel liquidity as the primary reason routed payments fail.1

Users or service operators may need to open channels, acquire inbound liquidity, rebalance, select fees, and keep enough on-chain funds for channel operations. Managed wallets can hide this work, but usually do so by adding custody or service-provider dependence.

Security is conditional inheritance

Lightning inherits Bitcoin at the channel-enforcement boundary, not for every operational property. A self-custodial peer must retain the latest channel state and respond if a counterparty broadcasts an obsolete state. It can monitor directly or delegate observation to a watchtower within the relevant timelock.2

Other risks include hot-wallet compromise, failed backups, forced closes during fee spikes, implementation defects, channel-partner availability, and denial of service through liquidity exhaustion.

Privacy improves without becoming anonymity

Ordinary payments are not broadcast to the global Bitcoin ledger. An intermediate node normally sees only adjacent peers and the amount it must forward, which can reveal less than an L1 transfer. The network still exposes channel topology, timing, amount constraints, and information held by endpoints or custodial wallets. Routing probes and correlations can narrow possible paths.

Lightning is therefore a privacy improvement over routine Bitcoin payments, not a substitute for a privacy-by-default currency such as Monero.

Best-fit boundary

LN is a strong fit for small, interactive, repeated BTC payments when participants can tolerate exchange-rate risk and someone can competently manage liquidity and custody. It is a weaker fit for occasional recipients with no inbound liquidity, offline self-custody without supporting infrastructure, large transfers that exceed practical route capacity, or users who require strong anonymity.

  1. Lightning Labs, “Sending Payments”, lnd documentation. First-party and living: it describes intended behaviour and can change without notice, and the wiki holds no snapshot of it. ↩

  2. Lightning Labs, “Watchtowers”, Lightning Network documentation. An implementer’s description of an optional service, not a measurement of how many nodes actually run one. ↩

Built on 3 sources (3 external).

Working out connections…