The Lightning Network, introduced in 2016 by Joseph Poon and Thaddeus Dryja, enhances Bitcoin’s payment capabilities. Rather than developing software directly from their whitepaper, the community opted to draft detailed specifications outlining the protocol’s function. Originally termed “Lightning RFC” — with RFC denoting “Request for Comments,” a common format for proposing internet and system standards — it was later rebranded as BOLTs, short for Basis of Lightning Technology.
BOLTs ensure that different Lightning Network versions can interact seamlessly. Much like the Internet Engineering Task Force (IETF) sets web standards, BOLTs offer a unified guideline for developers. This not only boosts security and shared insights on vulnerabilities but also encourages more developers to contribute, preserving the network’s unity.
Basis Of Lightning Technology
There are currently 11 BOLTs, each specifies a different aspect of the protocol. Here’s a summary of all of them:
BOLT 0: Introduction and Index
BOLT 0 provides a brief introduction to the Lightning Network. It offers insight into the network’s functioning, primarily through channels and conditional payments. The document features a glossary section, detailing essential terms related to the network. Fun fact: BOLT 0 even includes a whimsical “theme song” for the Lightning Network, adding a touch of levity to the technical introduction.
BOLT 1: Base Protocol
BOLT 1 serves as the cornerstone for node-to-node communication within the Lightning Network, outlining the fundamental message structures and connection protocols. It elucidates how nodes initiate, sustain, and multiplex their connections. The BOLT delineates the formatting of messages and presents a Type-Length-Value (TLV) format, ensuring the protocol can evolve without altering its core structure. It establishes essential data types, elaborates on initial connection messages, and defines messages for error handling and routine checks, such as ‘ping’ and ‘pong’ for maintaining active connections. Supplementary sections include test vectors for certain formats, guidance on message extensions, and standard references.
BOLT 2: Peer Protocol for Channel Management
BOLT 2 delves into the peer protocol responsible for channel management within the Lightning Network. At its core, the document defines what a channel is and explains how each can be uniquely identified. It then systematically lays out the communication messages used during three key stages of a channel’s lifecycle: its establishment, normal operation, and eventual closing. By categorizing and clarifying these message exchanges, BOLT 2 ensures seamless interactions between nodes as they initiate, transact within, and close out channels.
BOLT 3: Bitcoin Transaction and Script Formats
BOLT 3 provides a precise structure for on-chain transactions within the Lightning Network, ensuring both parties can validate signatures consistently. It defines the makeup of various transactions, such as the funding transaction output script, commitment transactions, and HTLC transactions. Key components detailed include transaction ordering, Segwit usage, output specifications, fees, and the construction of commitment transactions. The BOLT also delves deep into key derivations, setting requirements for per-commitment secrets and their efficient storage. To aid developers and network participants, the document offers several appendices with test vectors and expected weights for different transaction types. This meticulous layout guarantees secure, standardized operations across the network.
BOLT 4: Onion Routing Protocol
BOLT 4 outlines the structure and routing of an onion packet, facilitating payments from an origin node through various intermediate nodes, called hops, to a final destination. Drawing from the Sphinx construction, this protocol incorporates a per-hop payload. Each intermediate node can verify the packet’s integrity and ascertain the next forwarding node but remains oblivious to the full route details. The protocol enhances privacy by obfuscating details at each hop, ensuring potential network attackers cannot associate packets from the same route.
The origin node, equipped with the public keys of all nodes involved, establishes the route. It employs these keys to create shared secrets with every node, which in turn generate encryption keys and HMACs for packet integrity. To further privacy, only an ephemeral key representing the origin is visible at each hop, with subsequent hops blinding this key for unlinkability. This BOLT also delves into key generation, packet structures, and error handling, providing a comprehensive overview of the onion routing mechanism within the Lightning Network.
You can read more about how Onion Routing works here.
BOLT 5: Recommendations for On-Chain Transaction Handling
BOLT 5 outlines best practices for managing on-chain transactions in the Lightning Network. The foundation is built on cross-signed commitment transactions between two nodes, representing the channel’s current balance, which is adjusted with every payment.
The document provides a comprehensive guide on handling various channel termination scenarios (mutual closes and force closes), emphasizing commitment transactions and their nuances. It also delves into technical aspects such as HTLC transactions and penalty calculations, supplemented with appendices offering further details on transaction weights.
BOLT 7: P2P Node and Channel Discovery
BOLT 7 elucidates the mechanisms for peer-to-peer node and channel discovery within the Lightning Network, eliminating the need for third-party information distribution. Node discovery enables nodes to broadcast their identification and connection details, facilitating other nodes to establish connections and set up payment channels. On the other hand, channel discovery aids in building and maintaining an updated local perspective of the network’s structure, optimizing routing towards specific destinations.
The specification highlights three primary gossip messages supporting discovery: node_announcement for conveying node information, channel_announcement for introducing new channel connections between nodes, and channel_update for revising channel details. These messages ensure the network remains informed and can dynamically adapt to changes.
BOLT 8: Encrypted and Authenticated Transport
BOLT 8 focuses on ensuring that all interactions between Lightning nodes are both encrypted and authenticated, emphasizing the confidentiality of their transcripts and protection against harmful interference. Every node possesses a distinct long-term identifier, represented as a public key based on Bitcoin’s secp256k1 curve. This key plays a pivotal role in the protocol, enabling the establishment of encrypted and authenticated connections with peers and authenticating any node-associated information.
The specification delves into the intricacies of cryptographic messaging, explaining the handshake processes for authenticated key agreements and its versioning. It further details the Lightning message protocol, highlighting how to encrypt, send, receive, and decrypt these messages, along with key rotation measures. The document also provides transport test vectors for practical comprehension and verification.
BOLT 9: Assigned Feature Flags
BOLT 9 is all about managing special “flags” that help in identifying features within the Lightning Network. These flags, which can be thought of as labels or tags, are used to show what features a node or channel supports. Over time, new features might be added, so BOLT 9 keeps a record of these. It also has a system where new features start as optional and can later become mandatory, ensuring everything runs smoothly and everyone is on the same page.
BOLT 10: DNS Bootstrap and Assisted Node Location
BOLT 10 outlines a method for nodes in the Lightning Network to discover each other using the Domain Name System (DNS). This method assists in two main ways: firstly, helping new nodes find others when they’re just starting out; and secondly, aiding nodes in keeping track of peers they’ve previously interacted with. A special type of domain name server, called a DNS Seed, supports this process. Essentially, it helps nodes connect by answering specific queries about the network’s structure.
BOLT 11: Invoice Encoding for Lightning Payments
BOLT 11 introduces a straightforward and adaptable protocol designed for requesting Lightning Network payments. It’s tailored to be compatible with QR codes, simplifying the process for users to request and make payments. The protocol details how to encode payment details, ensuring that both the payer and the payee have a clear understanding of the transaction specifics. This facilitates seamless interactions between parties involved in a Lightning payment.
What Does it Take to Add or Change a BOLT?
The BOLTs are dynamic documents that continue to evolve with the progression of the Lightning Network. They aren’t static technical manifestos but rather are adaptable guides that can be amended to incorporate new features or enhancements as the network matures.
Take, for instance, the innovative concept of Splicing. Splicing is a feature that lets users adjust the size of a Lightning Channel seamlessly, without the need to undergo the cumbersome process of closing and then reopening the channel with a revised amount. Instead, Splicing enables this modification through just one on-chain transaction. This pivotal specification necessitated adjustments in three BOLTs: BOLT 2, BOLT 7, and BOLT 9.
To integrate such changes into the official BOLT specifications, there’s a rigorous process in place. Firstly, at least two distinct Lightning Client implementations must incorporate this feature, following the stipulations detailed in the BOLT. These implementations must be interoperable, ensuring that they function seamlessly with each other. Upon successful integration and testing, these changes can then be formally merged into the official BOLT specification.
On occasion, the evolution of the Lightning Network demands the introduction of an entirely new BOLT. A prime example is BOLT 12, which delineates a novel communication and payment paradigm. It empowers nodes to communicate over the Lightning Network directly, requesting invoices for transactions. While this may sound reminiscent of LNUrl in terms of user experience, BOLT 12 offers a distinct advantage: it operates natively within Lightning, negating the need for an external server, as is the case with LNUrl.
For the formal integration of a new BOLT like BOLT 12, the procedure remains consistent with the one outlined earlier. A minimum of two separate Lightning client implementations must successfully integrate the feature as per the BOLT’s guidelines, ensuring that they are mutually compatible. Once this criterion is met, the new BOLT can be officially inducted into the repository of BOLT specifications.
Technical Documents vs Reference Implementation
In the pioneering days of Bitcoin, the cryptocurrency’s code was created even before its now-famous Whitepaper was released. Over time, this foundational code matured and evolved into what the world recognizes today as “Bitcoin Core.” Interestingly, unlike the Lightning Network, Bitcoin does not have dedicated technical specification documents. This absence means that the ultimate guide to understanding the intricacies of Bitcoin is entrenched within the code of Bitcoin Core itself. This primary model, where the code serves as the principal guide, is referred to as a “reference implementation.”
When considering the development of a protocol, it’s essential to understand that there isn’t a singular “correct” approach. Each methodology, whether it be a reference implementation or specification documents, comes with its unique set of benefits and challenges. Specification documents, for example, offer developers a degree of flexibility, allowing for diverse implementations. It’s due to this freedom that the Lightning Network has witnessed a rise in multiple client implementations. In contrast, the Bitcoin network predominantly operates on Bitcoin Core, with the vast majority of its users and nodes relying on this single reference implementation.
However, the flexibility offered by specification documents doesn’t come without challenges. A significant downside of relying on these documents is the potential for interoperability issues. Since developers have a degree of creative freedom, discrepancies can arise between different implementations, leading to compatibility challenges. On the brighter side, specification documents encourage a competitive market for implementations. Such an environment often stimulates rapid innovation, as developers and teams continuously strive to enhance and refine their solutions. In essence, while each approach has its merits, the chosen method must align with the overarching objectives and requirements of the protocol in question.
