Communication layers on the Lightning Network

the structure of BOLT communication layers

The Lightning Network (LN) operates through a complex collection of protocols that form a protocol suite, also known as BOLTs (Basis of Lightning Technology). These BOLTs are detailed specifications that define the rules and procedures for how the Lightning Network should operate, ensuring that different LN implementations can communicate and work together seamlessly. Unlike Bitcoin, which has a reference implementation (Bitcoin Core) as its standard, Lightning uses these specification documents for interoperability and has several implementations.

The Layers

The BOLT protocol suite is generally classified into five distinct layers, where each layer builds upon and uses the protocols below it:

• Network Connection Layer: This foundational layer handles how nodes establish connections. It contains protocols that interact directly with internet core protocols like TCP/IP, as well as overlay networks such as Tor (v2/v3), and internet services like DNS. This layer is also responsible for the cryptographic transport protocols that protect Lightning messages.

  • BOLT 8: Encrypted and Authenticated Transport details how all interactions between Lightning nodes are encrypted and authenticated by default, using a unique public key as each node's identity. This ensures confidentiality, integrity, and protection against man-in-the-middle (MITM) attacks. The Lightning Network utilises a custom variant of the Noise Protocol Framework, for this purpose, offering strong security guarantees like authentication, encryption, forward secrecy, and identity privacy. The Noise_XK handshake specifically offers identity hiding for the responder's public key during connection initiation.

  • BOLT 10: DNS Bootstrap and Assisted Node Location outlines a method for nodes to discover each other using the Domain Name System (DNS). This helps new nodes find peers and allows existing nodes to track known peers. A new node can issue an SRV query to a DNS seed server (e.g., nodes.lightning.directory) to obtain a set of candidate bootstrap peers.

• Messaging Layer: This layer is responsible for defining message structures and encoding formats. It ensures an encrypted and secure communication and exchange of information via the network connection layer.

  • BOLT 1: Base Protocol serves as the cornerstone, outlining fundamental message structures and connection protocols, including how nodes initiate, sustain, and multiplex connections. It defines the Type-Length-Value (TLV) format, which allows the protocol to evolve by adding new features without altering its core structure. TLV records are used to extend messages in a forward and backward compatible manner, meaning older nodes can safely ignore information they don't understand.

    common ports:

    • Bitcoin mainnet port number 9735 or the corresponding hexadecimal 0x2607

    • Bitcoin testnet port number 19735 (0x4D17)

    • Bitcoin signet port number 39735 (0x9B37)

  • BOLT 9: Assigned Feature Flags governs the feature bits (or flags) that nodes use to communicate which capabilities they support. Features are typically assigned in pairs (optional and required bits), enabling nodes to determine compatibility with peers. The simple rule "it's OK to be odd" signifies that odd-numbered feature bits are optional, allowing for more flexible interactions. These feature bits are found in node_announcement, channel_announcement, and init messages, enabling peers to negotiate features for connections and payment types.

• Peer-to-Peer (P2P) Layer: This is the primary protocol layer for communication between Lightning nodes. It includes control messages and protocols for channel establishment, operation, and closing.

  • BOLT 2: Peer Protocol for Channel Management defines the rules for how payment channels can be opened and closed on the Lightning Network, and how nodes can update the channel's balance during normal operation. Channel establishment involves an exchange of messages such as open_channel, accept_channel, funding_created, funding_signed, and funding_locked.

  • BOLT 7: P2P Node and Channel Discovery elucidates the mechanisms for peer-to-peer node and channel discovery, eliminating the need for third-party information distribution. This is primarily achieved through the gossip protocol.

• Routing Layer: This layer defines the rules for creating payment channels between nodes and is responsible for routing payments between nodes end-to-end and atomically.

  • BOLT 4: Onion Routing Protocol outlines the structure and routing of an onion packet, facilitating payments from an origin node through intermediate nodes (hops) to a final destination. It describes how nodes build successive nested layers of encryption that are "peeled" off by each intermediary node, ensuring that only the sender knows the full route and only the immediate neighbors are known to each hop. This protocol is based on the SPHINX Mix Format. The onion packets are sent as part of the update_add_htlc message.

• Payment Layer: This is the highest layer of the network, presenting a reliable payment interface to applications. It defines the rules for using Hash Time-Locked Contracts (HTLCs) to route payments.

  • BOLT 11: Invoice Encoding for Lightning Payments introduces a straightforward and adaptable protocol for requesting Lightning Network payments, designed for compatibility with QR codes. BOLT 11 invoices include the payment hash, amount, description, and expiry time. A key limitation of BOLT 11 invoices is that they are generally single-use and specify a fixed amount.

  • BOLT 12: Offers is an upgrade that aims to address BOLT 11 limitations by enabling reusable payment requests and allowing static QR codes for both receiving and sending payments. Offers can be used multiple times and can be generated by either the sender or receiver. They contain enough information for a wallet to dynamically fetch a "real" invoice from the vendor through the Lightning Network itself, eliminating the need for external web servers.

Communication mechanisms

Key communication mechanisms within these layers include:

• Gossip Protocol: This peer-to-peer protocol allows nodes to share information about the topology of the Lightning Network. Nodes open encrypted connections and share (gossip) information received from other peers, such as newly created channels. This information is crucial for nodes to construct a channel graph (a map of publicly advertised channels and nodes) to find paths for payments. The main messages are node_announcement (communicates node public key, network address, and features), channel_announcement (proves channel existence and capabilities), and channel_update (describes routing policies like fees and timelocks for each channel direction). These messages are authenticated to prevent counterfeiting.

• Hash Time-Locked Contracts (HTLCs): HTLCs are a fundamental component for routing payments across multiple channels atomically and trustlessly. They are Bitcoin Scripts that require a recipient to either spend the payment before a deadline by presenting a secret preimage (derived from the payment hash in the invoice) or the sender can claim a refund after a timelock expires. The disclosure of the preimage propagates backward along the payment path, effectively settling all intermediate HTLCs. The update_add_htlc message is used to add an HTLC to a channel, while update_fulfill_htlc and update_fail_htlc are used for successful redemption or failure, respectively.

• Payment Routing: Payments are forwarded along a path of channels from the sender to the recipient. The sender (origin node) selects the entire payment path in a process called source-based pathfinding. The routing information for each hop is then encoded within the onion packet, encrypted layer by layer.

Changes to existing BOLTs or the introduction of new ones (like BOLT 12) require at least two distinct Lightning Client implementations to successfully integrate the feature and demonstrate interoperability before formal inclusion in the official specifications.