Briefing

Peer-to-peer payments

Bitcoin Lightning

Lightning is a payment layer on top of Bitcoin. It tries to make small or frequent transfers faster and cheaper, but only when liquidity, routing, and wallet support are in place. [R1][R2]

Back to handbook Go back

Sections

Use this page as a guide: start with the mechanism, then look at use cases, comparisons, and limits.

Plain termsChannels, routing, and invoices. Use casesWhere Lightning may actually help. Compare againstCheck the alternatives people already use. LimitsLiquidity, routing, and trade-offs.

In plain terms

Lightning uses payment channels, routing, and invoices so many transfers can avoid settling on Bitcoin's base layer every time. [R1][R3]

Core mechanism

  • Two peers open a payment channel. [R2]
  • Payments update channel balances instead of putting every transfer on chain. [R1]
  • Recipients create invoices that specify amount and payment path details. [R3]
  • Routing nodes forward payments across connected channels. [R3]

What Lightning is good at

  • Near-instant settlement between participants when the route is available. [R1]
  • Small and frequent payments where on-chain fees would be awkward. [R1]
  • Transfers that need a direct peer-to-peer feel rather than a platform account. [R1]
  • Low-fee movement where channel liquidity is actually available. [R4]

Why people care about it

The strongest case focuses on situations where Lightning can help and on-chain Bitcoin is too slow or too expensive.

Payments

Useful when the topic is direct value transfer between peers and the route can be maintained. [R1]

Micropayments

Can work for small recurring or per-use payments if liquidity and wallet design are good enough. [R1]

Remittances

Can be part of the conversation when fees and settlement speed matter, though simpler routes often remain available. [R4]

P2P infrastructure

Fits the handbook's interest in systems that reduce reliance on one payment operator. [R1]

Compare against

In ordinary life, the comparison is usually with existing payment rails rather than a blank sheet of paper.

Incumbent rails

  • Faster Payments for domestic transfers. [R4]
  • Cards for point-of-sale spending and consumer protection. [R1]
  • Bank transfers for users who value support and familiarity over protocol control. [R1]

Where Lightning differs

  • It can settle through a payment path rather than a card network. [R1]
  • It reduces reliance on one central platform if the wallet and routing layers work well. [R3]
  • It is more useful when the user accepts some operational complexity in exchange for lower transfer friction. [R4]

Limits and trade-offs

What critics are right about

  • Channels need capital and liquidity. [R4]
  • Routing can fail if the network path is unavailable. [R3]
  • Users still need on-chain Bitcoin for opening and closing channels. [R2]
  • Custody choices matter a lot, and many users will prefer to avoid managing them directly. [R1]

Boundaries

  • Lightning gives no reason to relax consumer protection. [R1]
  • It is often less simple than ordinary payment rails for retail users. [R1]
  • It only works well when routing and liquidity are good enough. [R4]
  • Base-layer Bitcoin transactions still matter for opening and closing channels. [R2]

Primary sources

Further reading

  • Compare Lightning with Nostr if you want another example of a protocol that relies on keys and network relays.
Back to handbook Go back Next topic: File storage

Sources

References