bLIP (Bitcoin Lightning Improvement Proposal)

What Is a bLIP?

A bLIP (Bitcoin Lightning Improvement Proposal) is a design document that describes an optional feature or application-layer extension for the Lightning Network. Unlike BOLTs, which define the mandatory protocol rules that all Lightning implementations must follow, bLIPs cover features that individual implementations can adopt independently. A node that supports a particular bLIP can interoperate with nodes that do not: the feature degrades gracefully rather than breaking compatibility.

The bLIP framework was created because the BOLT process, while essential for core protocol stability, became a bottleneck for innovation. Features that were useful but not universally needed would stall in the BOLT review process for months or years. bLIPs provide a lighter alternative: a place to formally document optional features, reserve the identifiers they need (feature bits, TLV types, message types), and enable interoperability between implementations that choose to support them.

The process is analogous to how BIPs work for Bitcoin itself. BOLTs are to Lightning what the Bitcoin consensus rules are to Bitcoin Core: mandatory. bLIPs are to Lightning what informational or optional BIPs are to Bitcoin: useful standards that nodes can choose to adopt.

How It Works

The bLIP process is governed by bLIP-1, the foundational document that defines the submission and review workflow. The process is intentionally lightweight compared to the BOLT process.

The bLIP Lifecycle

1. An author drafts a proposal following the template defined in bLIP-1, including a concise technical specification, a rationale for the feature, and any backwards-compatibility considerations
2. The author checks the lightning-dev mailing list (now hosted on Delving Bitcoin) to ensure no similar proposal exists
3. The author reserves any required feature bits, message types, or TLV type identifiers in the bLIP-2 registry to avoid collisions with other proposals
4. The proposal is submitted as a pull request to the lightning/blips repository on GitHub
5. bLIP editors review the proposal for completeness and formatting but do not pass judgment on the feature's merit or usefulness
6. Once merged, the bLIP becomes an Active specification that implementations can reference

This stands in contrast to the BOLT process, where a feature typically requires at least two independent implementations demonstrating interoperability before the specification is finalized. bLIPs can be merged with a single implementation, since adoption is voluntary.

The bLIP-2 Registry

A critical piece of the bLIP infrastructure is the bLIP-2 registry of reserved values. The Lightning protocol uses several namespaces where collisions could cause problems:

• Feature bits: flags exchanged during the channel handshake that advertise supported capabilities
• Message types: numeric identifiers for peer-to-peer messages sent over the BOLT 8 encrypted transport
• TLV (Type-Length-Value) types: extension fields that can be attached to existing messages without breaking backwards compatibility

Before a bLIP is merged, the author must register any identifiers the feature needs. For example, keysend uses TLV type 5482373484 in the payment onion payload, and feature bits 54/55 in the node's init message. Registering these values prevents two bLIPs from accidentally using the same identifier.

bLIPs vs. BOLTs

The distinction between bLIPs and BOLTs can be summarized as prescriptive versus descriptive:

If a bLIP feature gains enough adoption to become effectively universal, it may be promoted into the BOLT specification. The bLIP process serves as a proving ground where ideas can mature before they are standardized at the protocol level.

Notable bLIPs

bLIP-3: Keysend

Keysend allows sending Lightning payments without requiring the receiver to generate an invoice first. The sender picks a random 32-byte preimage, includes it in a TLV record (type 5482373484) within the payment onion, and routes the payment to the recipient's node. The receiver extracts the preimage from the TLV and uses it to settle the HTLC.

Keysend was already widely deployed before bLIPs existed. bLIP-3 retroactively documented the feature to formalize what implementations were already doing, making it one of the first proposals merged when the bLIP repository launched in December 2021.

# Send a keysend payment using Core Lightning
lightning-cli keysend \
  024b9a1fa... \   # destination node public key
  10000             # amount in millisatoshis

bLIP-10: Podcasting 2.0

This bLIP standardizes how podcast listeners send satoshis to podcast hosts over Lightning. It defines two payment types: per-minute streaming payments (sent automatically while listening) and manual boost payments (one-time tips). Both use TLV type 7629169 to encode metadata about the podcast, episode, and payment split among contributors.

bLIP-50 through bLIP-55: LSP Specifications

The Lightning Service Provider specification suite (LSPS) was incorporated into the bLIP framework. These specs standardize how mobile wallets interact with LSPs for channel management:

• bLIP-50 (LSPS0): transport layer using JSON-RPC 2.0 over BOLT 8 peer messages
• bLIP-51 (LSPS1): channel request protocol for clients that need inbound liquidity
• bLIP-52 (LSPS2): just-in-time (JIT) channel negotiation, where the LSP opens a channel when an incoming payment arrives and deducts the opening fee from that payment

The LSPS suite is a good example of why bLIPs exist: these specifications are critical for mobile wallet user experience but do not need to be implemented by every routing node on the network. For a deeper look at how these standards are shaping wallets, see the LSPS specification progress research article.

Why bLIPs Matter

The Lightning Network's growth depends on more than just the core protocol. Application developers need standardized ways to build features that go beyond basic payment routing: invoiceless payments, streaming micropayments, wallet-LSP communication, and experimental protocol extensions.

Before bLIPs, developers had two options: push a feature through the full BOLT process (slow and often blocked by lack of consensus) or implement it as a proprietary extension (fast but creates fragmentation). bLIPs provide a middle path: formal documentation with reserved identifiers, enabling interoperability without requiring universal adoption.

This matters for the broader Bitcoin Layer 2 ecosystem as well. Projects building on Lightning, including second-layer protocols like Spark, benefit from a richer set of standardized building blocks. Features proven through the bLIP process can eventually be promoted to BOLTs, while those that serve niche use cases remain available without burdening the core specification.

Risks and Considerations

Fragmentation

The primary criticism of bLIPs is that they can fragment the network. If different implementations adopt different subsets of bLIPs, users may find that a feature works with one wallet but not another. This is by design (optional features are optional), but it can create confusion about what the Lightning Network actually supports.

Maintenance Burden

Each bLIP adds code and complexity to implementations that adopt it. Over time, maintaining backwards compatibility with multiple optional features increases the testing surface and can introduce subtle bugs. Implementation teams must decide which bLIPs justify the engineering investment.

No Enforcement Mechanism

The bLIP-2 registry is a coordination tool, not an enforcement mechanism. There is no technical barrier preventing someone from deploying a feature that uses an already-reserved TLV type or feature bit. In practice, the social convention of registering values has worked well, but conflicts remain possible.

Quality Variance

Because bLIP editors review only format and completeness rather than technical merit, the quality of individual bLIPs can vary. Some proposals are well-tested and widely deployed (like keysend), while others may be experimental with limited real-world validation. Developers should evaluate each bLIP on its own merits before implementing it.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.