The Lightning Network(LN) is a revolutionary solution for faster and cheaper Bitcoin transactions. The Basis of Lightning Technology (BOLT) documents define the network protocol specifications, which describe a layer-2 protocol for off-chain bitcoin transactions. The BOLTs are split into parts(currently 10) and updated after discussions and consensus by LN operators.
The LN relies on a robust communication protocol to facilitate interactions between nodes. The cornerstone of this protocol is BOLT 1, a set of specifications that defines the structure and behavior of messages exchanged within the Lightning Network.
BOLT 1 dictates how messages are formatted, ensuring all nodes speak the same language. Imagine it as a universal grammar for the network. Each message adheres to a specific structure, containing an identifier for its purpose (like "open channel" or "invoice"), relevant data (channel value, payment amount), and optional additional information. This well-defined format ensures clear communication and avoids misunderstandings between nodes.
In this article, you will explore the BOLT 1 specification, its details, and some examples of its implementation.
BOLT 1 Protocol Specifications
The LN networks mostly use TCP connections between peer nodes. For the LN to connect to Bitcoin, various ports are used depending on the network. They include the Bitcoin mainnet with port number 9735 or the hex 0x2607, testnet with port number 19735 (0x4D17), and signet with port number 39735 (0x9B37).
BOLT1 specifications can be split into:
Connection Handling and Multiplexing
BOLT 1 describes how peer LN nodes should initiate and keep alive connections. To avoid overwhelming the network, LN nodes are required to use only one connection per peer. After opening a connection with a peer, a node can create multiple channels over the single connection(multiplexing).
LN messages contain a channel ID within their payload to support this, identifying and directing the message to the appropriate channel handler on the receiving node.
Lightning Message Format
The Lightning Network uses a specific message format to ensure clear and secure communication between nodes. After decryption, these messages all share a common structure:
Type (2 bytes): This field acts like a message identifier, indicating the message's purpose. It's a big-endian value, meaning the most significant byte comes first. The fun part? The specification allows for odd-numbered types! This means nodes can send messages with new or experimental functionalities (within a specific range) even if the recipient doesn't necessarily understand them yet. It allows for future expansion of the protocol.
Payload: This section carries the message's core data, which can vary in length. The format of this data depends on the message type (identified in the first field). Imagine it as a box containing specific details relevant to the message's purpose, like channel capacity for an "open channel" message or payment amount for an "invoice" message.
Optional Extension (TLV Stream): This final part is an add-on for some messages. It uses a format called TLV (Type-Length-Value) to provide additional data if needed. Think of it as attaching extra information to a message for specific situations.
The message types are logically grouped into five categories based on their most significant bit. These categories cover various functionalities within the Lightning Network:
Setup & Control (0-31): These messages handle connection setup, control flow, feature negotiation, and error reporting. They lay the groundwork for communication between nodes.
Channel (32-127): These messages manage the creation and closure of payment channels, the core mechanism of the Lightning Network.
Commitment (128-255): These messages focus on updating the current commitment transaction within a channel. This includes adding, removing, and settling special HTLCs (Hashed Time Locked Contracts) payment mechanisms, adjusting fees, and exchanging signatures to ensure secure updates.
Routing (256-511): Routing messages are about navigating the Lightning Network. They handle node and channel announcements, allowing nodes to discover payment paths and even facilitate active exploration of potential routes for efficient transactions.
Custom (32768-65535): This category is reserved for experimentation and future applications. It allows developers to create new message types for innovative functionalities beyond the core functionalities defined in the current specifications.
Setup & Control Messages in the Lightning Network
This protocol's first group of messages, occupying message types 0-31, is crucial in laying the groundwork for secure and efficient node interaction. Setup messages initiate the handshake, allowing nodes to discover each other, establish a secure connection, and agree on the communication rules they'll follow. This initial exchange involves messages like:
init (Type 16): This message is a formal introduction sent by the initiating node. It contains information about the node's supported features and capabilities. In response to the init message, nodes exchange their feature sets. This negotiation ensures both nodes understand the functionalities they can leverage during communication.
error (Type 17): If a node encounters an issue processing a message or violates protocol rules, it sends an error message (Type 16) detailing the problem.
ping (Type 18)/pong (Type 19): These messages establish a basic liveness check. They verify that the other node is still available and responsive, ensuring smooth communication.
warning (Type 01): This message conveys a non-critical issue encountered during communication.
Channel Operations
The type 32-127 messages manage channel operations within the LN network. They include:
open_channel (Type 32): This message initiates the channel opening process. A node proposes the desired channel size, fees, and other parameters to another node.
accept_channel (Type 33): After receiving the
open_channelmessage, the recipient node can agree to open the channel by sending this message. It might also include counter-proposals for fees or other parameters.funding_created (Type 34): Both nodes have agreed and created a multi-signature transaction that locks up the initial funds for the channel. This transaction requires signatures from both parties to spend the funds.
funding_signed (Type 35): Each node individually signs the multi-signature transaction created in
funding_created.funding_locked (Type 36): Both nodes have broadcasted their signatures, locking the funds in the multi-signature transaction on the Bitcoin blockchain. This marks the successful creation of the channel and allows for sending and receiving payments within the channel (Channel Operation).
Commitment Transaction Operations
These messages indicate off-chain transactions between the parties involved in the LN channel. They include:
128: update_add_htlc: This message proposes adding a Hashed Time Locked Contract (HTLC) to the channel.
130: update_fulfill_htlc: This message indicates that a previously added HTLC has been completed. The receiving party acknowledges receiving the payment and the preimage to unlock the HTLC.
131: update_fail_htlc: This message signifies that an HTLC has failed. The preimage to unlock the HTLC wasn't provided within the specified time frame, or other conditions weren't met.
132: commit_sig: This message exchanges signatures on a new commitment transaction. This updates the channel state, reflecting changes like added/removed HTLCs or adjusted fees.
133: revoke_and_ack: It allows a node to revoke a previous commitment transaction and claim the channel funds on-chain if the other node breaches the channel rules.
134: update_fee: This message proposes modifying the channel's routing fees for future payments within the channel.
Routing Operations
Routing messages (256-511) enable efficient payment routing across the Lightning Network. They facilitate channel and node announcements, allowing nodes to discover potential payment paths. Channel graph syncing messages ensure all nodes share a consistent view of the network's current state.
channel_announcement (Type 256): This message broadcasts the creation of a new channel to the network. It allows other nodes to discover the channel and potentially use it to route payments.
node_announcement (Type 257): This message informs the network about a new node joining the Lightning Network. It allows for route discovery and communication between nodes.
channel_update (Type 258): This message updates the network about changes to an existing channel, e.g., capacity and fees.
query_short_chan_ids (Type 261) & reply_short_chan_ids_end (Type 262): These messages are used to discover new channels and update the network graph efficiently. Nodes exchange a compressed list of channel identifiers, allowing faster discovery than sending full channel details.
query_channel_range (Type 263) & reply_channel_range (Type 264): This message pair allows nodes to request and receive detailed information about specific channels within a certain range of channel IDs.
Conclusion
This article explored LN BOLT 1 specifications and the different message types used in the Lightning Network protocol. We discussed how channels are established and funded (messages 32-36), how commitment transactions are updated within a channel (messages 128-255), and how nodes discover and navigate the network to route payments (messages 256-511). Finally, we touched upon the custom message category (32768-65535), allowing experimentation and future applications beyond the core functionalities.
Understanding these message types provides a deeper understanding of the Lightning Network's operation. By establishing secure channels, updating their state through commitment transactions, and efficiently routing payments across the network, the Lightning Network facilitates faster and cheaper transactions than traditional on-chain Bitcoin transactions.