What is a BOLT?

The BOLT acronym stands for: Basis of Lightning Technology. A BOLT is a set of rules that define the Lightning specification that is most used today and referred to as the Lightning Network. Most Lightning implementations follow the standards set by the BOLTs.

Because the development of the Lightning network is distributed, there are multiple companies working on their independent implementations. Each one has to be compatible with others for the Lightning network to function as one network.

The current bolt implementations are:

• C-lightning by Blockstream
• Eclair by ACINQ
• LND by Lightning Labs
• Python Lightning by Electrum
• Rust-Lightning and LDK by Spiral

Other BOLT compliant implementations exist such as Breez, Muun, Pandora Core LNP/BP, Simple Bitcoin Wallet, but are less used and well known. Breez and Muun maintain their own fork of LND for their wallet software.

The history of the BOLT process

The history of the BOLT process goes back to a 2016 meeting in Milan. The lightning devs kicked off the BOLTs drafting and review process, describing how interoperability between each of the Lightning implementations should work, as well what general direction the development should be focused on. Since then, for ongoing dev communication there are irc biweekly meetings and an annual in-person meeting.

The process of creating a BOLT

First, discuss the potential change on the Lightning dev mailing list to engage the community and receive feedback. Then, put in a pull request to an implementation to test the proposal. Finally, for a new BOLT to be merged to the specification, at least two independent implementations must successfully test interoperability as peers on the lightning network (based on the ITF method of how internet specifications are revised).

Currently, there are 11 BOLTs

Developers have their own quirks such as starting their counts with the number 0. So the BOLT #0 is the introduction and table of contents for the other BOLTs.

1. BOLT #1: Base Protocol
   • Basic node communication
2. BOLT #2: Peer Protocol for Channel Management
   • How to open and close channels
3. BOLT #3: Bitcoin Transaction and Script Formats
   • How to exchange bitcoin transactions and signatures
4. BOLT #4: Onion Routing Protocol
   • How to send a payment to the next node along each “hop”
5. BOLT #5: Recommendations for On-chain Transaction Handling
   • How to deal with a channel closes on chain
6. Attend the next spec meeting to ask why BOLT 6 doesn’t exist!
7. BOLT #7: P2P Node and Channel Discovery
   • How you find out about other nodes and their aliases
8. BOLT #8: Encrypted and Authenticated Transport
   • How nodes communicate using authentication and encryption
9. BOLT #9: Assigned Feature Flags
   • How nodes know which features other nodes also use
10. BOLT #10: DNS Bootstrap and Assisted Node Location
    • How to find out who is on the Lightning Network
11. BOLT #11: Invoice Protocol for Lightning Payments
    • How to send bitcoin on Lightning

Lastly we have BOLT #12 (which is not yet formalized as an official BOLT) is more on how to send bitcoin on Lightning, but with different tools under the hood.

How is a Lightning BOLT different from a Bitcoin BIP?

Both BOLTs and BIPs are forms of development proposals. In Lightning, a proposal only becomes a BOLT after two independent implementations have successfully tested interoperability. In Bitcoin, a BIP is more of an opt-in proposal standard for implementers to ensure interoperability.

A Lightning bLIP is an opt-in specification for experimental features. The bLIP process isn’t entirely pinned down yet, because it’s still unclear when proposals are within the BOLT process and what’s outside of it.

In the upcoming deep dives, we will be exploring the various methods of paying people on Lightning and the tradeoffs between: BOLT 11, LNURL, Keysend / MMP / AMP, Lightning address, and BOLT 12.