The BIPs behind the Lightning Network

The Lightning Network is not defined by a BIP: its protocol is specified in separate documents called BOLTs. But Lightning only works because of Bitcoin features that are BIPs. The most important are SegWit's malleability fix (BIP 141), the timelock opcodes CHECKLOCKTIMEVERIFY (BIP 65) and CHECKSEQUENCEVERIFY (BIP 112, with BIPs 68 and 113), and fee-bumping policies such as anchors and package relay. This guide maps each BIP to what Lightning uses it for, and to the proposals that would change how channels work.

Updated 2026-10-20 · 7 min read

BOLTs vs BIPs

The Lightning Network is specified in the BOLTs ("Basis of Lightning Technology"), maintained by Lightning implementers at github.com/lightning/bolts. BOLTs cover channel messages, transaction formats, routing and invoices. BIPs cover Bitcoin itself: consensus rules, node policy, wallets and payment formats.

Lightning sits on top of Bitcoin. Channels are opened and closed with ordinary Bitcoin transactions, and the safety of the funds in a channel depends on Bitcoin enforcing certain scripts and relaying certain transactions in time. Every one of those features came through a BIP.

How a Lightning channel uses Bitcoin

A simplified picture of a channel between Alice and Bob:

1. Funding. They lock coins in a 2-of-2 multisig output that needs both signatures to spend.
2. Commitment transactions. Before broadcasting the funding transaction, and after every payment, they sign a new transaction that spends the funding output and splits the money according to the current balance. These stay unbroadcast.
3. Revocation. When they move to a new balance, each side hands over a secret that lets the other take everything if an old commitment transaction is ever broadcast. To make that punishment possible, each party's own output in their commitment transaction is delayed by a relative timelock.
4. Payments across channels use HTLCs: outputs claimable with a secret before a deadline, or refundable after it.
5. Closing. The pair signs a final transaction together, or one side broadcasts the latest commitment transaction and waits out the delay.

Each step relies on a BIP.

The BIPs Lightning depends on

Multisig outputs: BIPs 11, 16 and 141

The 2-of-2 funding output builds on standard multisig scripts (BIP 11) wrapped in a script hash. The current BOLTs use a SegWit P2WSH output, defined in BIP 141; P2SH (BIP 16) introduced paying to a script hash in the first place.

SegWit's malleability fix: BIP 141

Lightning needs to sign transactions that spend outputs of transactions not yet in a block. If a third party could change the funding transaction's ID before it confirmed, the pre-signed commitment transactions would point at the wrong txid and the funds could be stuck. SegWit removed signatures from the txid, ending third-party malleability. BIP 141 names this use case directly: it "allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network."

Absolute timelocks: BIP 65

BIP 65 by Peter Todd turned OP_NOP2 into OP_CHECKLOCKTIMEVERIFY (CLTV), which keeps an output unspendable until a given block height or time. HTLC deadlines are absolute block heights, so HTLC outputs and the transactions that time them out depend on CLTV and the transaction's nLockTime. Each hop along a route uses a slightly earlier deadline than the hop before it, so every forwarding node has time to claim its incoming HTLC after learning the secret from the outgoing one.

Relative timelocks: BIPs 68, 112 and 113

BIP 68 made the nSequence field enforce relative lock-times, and BIP 112 added OP_CHECKSEQUENCEVERIFY (CSV) so a script can require that an output has aged a certain number of blocks. BIP 113 made time-based locks use the median time of the last 11 blocks. All three activated together at block 419,328 in July 2016.

CSV is what makes revocation work. BIP 112 includes a Lightning example in which Alice's own output in her commitment transaction is spendable by her only after a "24h" delay, but immediately by Bob if he knows the revocation secret. With only absolute timelocks, BIP 112 notes, a channel would have a fixed deadline "that cannot be pushed back without hitting the blockchain". The delay gives the honest party time to react. See BIP 65 vs BIP 112.

Hashed timelock contracts: BIP 199

BIP 199 by Sean Bowe and Daira Hopwood describes the HTLC pattern: OP_IF a hash check (OP_SHA256 or OP_HASH160) plus the seller's key, OP_ELSE a timeout (CLTV or CSV) plus the buyer's key. Its Lightning example: Alice hashes a secret, Bob and Carol forward HTLCs locked to the same hash, and "only when Alice releases the preimage" does value move along the route. Lightning's HTLC scripts in the BOLTs follow the same idea with revocation added.

Fee bumping: BIPs 125, 331, 431 and 433

Commitment transactions are signed long before they may be broadcast, so their fee can be too low when it matters, often when a counterparty has disappeared or is cheating and an HTLC deadline is near. Being able to add fees at broadcast time is therefore a security requirement, not a convenience.

• BIP 125 replace-by-fee and child-pays-for-parent are the basic tools; the RBF guide explains both.
• Lightning's "anchor outputs" channel type adds two small outputs, one for each party, to commitment transactions so either side can attach a fee-paying child. BIP 431 explains why two anchors were needed and how they rely on Bitcoin Core's "CPFP carve out" rule.
• BIP 331 (Gloria Zhao) proposes package relay so a low-fee parent and its fee-paying child travel together; its motivation lists Lightning's HTLC-timeout transaction among the time-sensitive transactions it is meant to protect.
• BIP 431 TRUC transactions (nVersion=3) and BIP 433 Pay to Anchor (P2A) outputs together allow one keyless anchor and stricter anti-pinning limits, a design aimed at simpler and safer Lightning commitment transactions.

Taproot and MuSig2: BIPs 340, 341 and 327

With Taproot (BIP 341) and MuSig2 (BIP 327), the 2-of-2 funding output can be a single aggregate key. A cooperative close then looks like any single-signature Taproot spend, and the scripts for disputes stay hidden in the tree unless needed. Taproot-based channel types are being developed for the BOLTs. BIP 340's "Applications" section also describes adaptor signatures, which could replace HTLC hash locks with point time-locked contracts (PTLCs) that avoid reusing the same hash at every hop.

Addresses, invoices and payment links: BIPs 173, 321 and 353

Lightning invoices (BOLT 11) are encoded with Bech32 from BIP 173, which is why mainnet invoices begin with "lnbc". BIP 321 lets a bitcoin: URI carry a lightning= BOLT 11 invoice or an lno= BOLT 12 offer alongside, or instead of, an on-chain address; see BIP 21 vs BIP 321 and the Bitcoin URI tool. BIP 353 stores payment instructions, such as BOLT 12 offers, in DNS so people can pay a name like ₿[email protected].

Summary: BIP to Lightning feature

More on the Lightning topic page and the time locks topic page.

Proposals that would change Lightning

Several covenant and signature proposals are motivated largely by Lightning. They are proposals, not current rules; each BIP page shows its status, and the covenants guide covers the arguments for and against.

• LN-Symmetry (eltoo) with APO. BIP 118 (Christian Decker, Anthony Towns), which began as SIGHASH_NOINPUT, lets a signature attach to any output with a compatible script. That allows a channel where any newer state can replace any older one, so there are no penalty transactions and each side only needs to keep the latest state.
• LN-Symmetry with CTV and CSFS. BIP 348 shows that BIP 119 CTV plus CHECKSIGFROMSTACK can do the same job. The LNHANCE bundle and BIP 448 (with OP_TEMPLATEHASH from BIP 446) are variations on this approach. BIP 446 adds that it could also remove the need to exchange HTLC signatures in today's Lightning.
• Channel factories. BIP 119 discusses batched channel creation, where one on-chain output funds many channels.

Do you need to know any of this to use Lightning?

No. Wallets and Lightning nodes handle these details. They matter when you want to understand what keeps channel funds safe: a node that can't get a transaction confirmed before a timelock expires can lose money, which is why fee-bumping policy gets so much attention from Lightning developers.