Home › Glossary › Lightning Network

Lightning Network

Also called: Lightning, LN, Lightning payments, payment channels, layer 2.

The Lightning Network is a layer-2 payment network on Bitcoin: users pay through chains of off-chain channels and settle on-chain only when needed.

The Lightning Network is a network of payment channels built on top of Bitcoin. Two parties lock bitcoin in a shared 2-of-2 output, then pay each other by exchanging signed but unbroadcast transactions that update the balance. Payments can be routed across several channels, so you can pay anyone connected to the network. Only opening and closing a channel touch the blockchain, so payments are fast and can be very small. It was first described in a 2015 paper by Joseph Poon and Thaddeus Dryja.

How Lightning works

  • Channels: each payment creates new commitment transactions that either side could broadcast. Old states are revoked: if someone broadcasts one, the other party can claim all the funds while the cheater's output is still locked by a CSV delay.
  • Routing: payments travel through intermediaries using HTLCs, contracts that release funds when a secret is revealed or refund after a timelock, so either every hop is paid or none is.
  • Fees: commitment transactions are signed long before they may be broadcast, so fees are added later with CPFP through anchor outputs.

BIPs Lightning depends on

Lightning's own protocol is specified in the BOLT documents, not in BIPs, but it relies on Bitcoin upgrades: BIP 65 and BIP 112 timelocks with BIP 68 relative locks, BIP 141 (SegWit) to fix malleability, Taproot and MuSig2 (BIP 327) for more private channels, and mempool work such as package relay (BIP 331), TRUC transactions (BIP 431) and P2A anchors (BIP 433). Proposals such as BIP 118 (ANYPREVOUT, for the "eltoo" channel design) aim to simplify channels further.

The Lightning BIPs guide goes through each one, and the Lightning topic lists related proposals.

BIPs that define Lightning Network

  • BIP 141 (SegWit): Segregated Witness (Consensus layer): Deployed. Defines Segregated Witness (SegWit), which moves signatures into a separate "witness" section of each transaction while remaining compatible with older nodes. This fixed transaction malleability,…
  • BIP 65: OP_CHECKLOCKTIMEVERIFY: Deployed. Adds OP_CHECKLOCKTIMEVERIFY, a script command that keeps coins unspendable until a chosen date or block height. It enables time-locked savings, escrow with deadlines, and payment channels such as…
  • BIP 68: Relative lock-time using consensus-enforced sequence numbers: Deployed. Gives transactions a "relative lock-time," so a coin cannot be spent until a set number of blocks or amount of time has passed since it was confirmed. This is an essential building block for payment…
  • BIP 112: CHECKSEQUENCEVERIFY: Deployed. Introduces CHECKSEQUENCEVERIFY, a script instruction that lets coins be locked until a certain amount of time has passed since they were received. This 'relative timelock' is a key building block…
  • BIP 199 (HTLC): Hashed Time-Locked Contract transactions: Closed. Defines the hashed time-locked contract (HTLC), a script where funds can be claimed by revealing a secret before a deadline or reclaimed by the sender afterward. HTLCs are a core building block for…
  • BIP 327: MuSig2 for BIP340-compatible Multi-Signatures: Deployed. Standardizes MuSig2, a scheme that lets several people jointly create a single signature that looks like an ordinary one-person Taproot signature. This makes shared-control wallets cheaper and more…
  • BIP 331: Ancestor Package Relay: Draft. Lets nodes request and share an unconfirmed transaction together with the parent transactions it depends on, as a single package. This helps low-fee parents get relayed when a child pays extra fees…
  • BIP 431 (TRUC transactions): Topology Restrictions for Pinning: Draft. Explains 'pinning', a problem where someone can block a transaction from being replaced with a higher-fee version, which can endanger time-sensitive protocols like Lightning. It describes stricter…
  • BIP 433: Pay to Anchor (P2A): Draft. Defines Pay to Anchor, a tiny standard output that anyone can spend without a signature. Its purpose is to act as a hook for fee-bumping: by spending it in a follow-up transaction, any party can add…
  • BIP 118: SIGHASH_ANYPREVOUT for Taproot Scripts: Draft. Proposes SIGHASH_ANYPREVOUT, a signature type for Taproot scripts that does not commit to the exact coin being spent, so one signed transaction can be attached to any compatible coin. This would…

Related terms

  • HTLC: An HTLC (hashed time-locked contract) pays whoever reveals a secret before a deadline and refunds the sender after it; Lightning routes payments with them.
  • Anchor output: An anchor output is a small extra output on a pre-signed transaction that can be spent by a CPFP child to add fees when the transaction is broadcast.
  • Timelock: A timelock is a rule that stops bitcoin from being spent until a set block height or time, or until the coin has aged a set amount since it confirmed.
  • MuSig2: MuSig2 is a Schnorr multi-signature scheme (BIP 327): several signers share one aggregate key and produce one ordinary-looking signature.

Learn more

Guides