The Lightning Network is a second-layer protocol for Bitcoin, created to solve the network’s scalability issues. On Bitcoin’s first layer, transactions can have high fees and take from 10 minutes to hours to confirm. However, on the Lightning Network, transactions have negligible fees and are instant, without the need to confirm each transaction directly on the blockchain.

Despite being a relatively new technology—it was created in 2017—the Lightning Network has been developing year after year and has proven to be an effective solution for scaling Bitcoin.

Today, various Lightning wallets and exchanges support this network, facilitating cheap and fast payments without relying on intermediaries.

Additionally, the Lightning Network is decentralized and open-source. This allows anyone to access the code, propose improvements, and contribute to the network’s development.

Just as in the first layer of Bitcoin, where developers can propose improvements through BIPs, in the Lightning Network, improvements are proposed through BOLTs.

In this article, you’ll understand what BOLTs are and the main ones in operation.

Let’s dive in!

How does the Lightning Network work?

Before understanding what BOLTs are, it’s worth noting that the Lightning Network is not a blockchain but a network of payment channels between Lightning nodes that establish peer-to-peer connections by locking funds within the network.

So, since it doesn’t have a blockchain to perform operations, transactions are made “off-chain” by the users. In other words, funds never leave the Lightning Network; they keep moving from one channel to another.

What are Lightning channels?

Lightning channels allow users of the Lightning Network to send and receive money among themselves. They function like interconnected money tubes, facilitating the transfer of payments between users. Thus, each Lightning channel is established between two nodes on the Lightning Network.

Example of how the lightning channels function

To transfer funds to the Lightning Network, a channel must be opened. Then, once opened, the user can transact payments within the channel limits and exit the network at any time by closing the channel and transferring the funds back to the Bitcoin blockchain, the first layer.

Why was the Lightning Network created?

The Lightning Network was created to enable the use of Bitcoin for small value payments, such as a cup of coffee, with cheap fees, instant transactions, and global reach.

To give an idea, while the Lightning Network can process up to one million transactions per second (TPS) and settle all of them immediately, Bitcoin can process only about 7 transactions per second.

In September 2023, River released a report estimating that between 279,000 and 1 million wallets were actively using the Lightning Network, performing approximately 6.6 million transactions. This represents a growth of 1,212% in two years, compared to the 501,000 transactions recorded in August 2021.

As more people start using the Lightning Network, developers receive feedback, analyze critical points, identify potential security flaws, improve privacy, and discover new use cases.

From this, protocol improvements are discussed, and this is where BOLTs (Basis of Lightning Technology) come into play. These are specifications guiding these updates.

What is BOLT in the Lightning Network?

BOLT stands for Basis of Lightning Technology and is a set of technical specifications or protocols that define the rules and procedures for the functioning of the Lightning Network.

BOLT was launched in 2017 by a group of Lightning Network developers and has undergone several updates and revisions since then.

Additionally, these protocols are open-source and available to anyone who wants to use or develop applications and services related to the Lightning Network.

BOLT covers various topics, including payments, channel opening and closing, routing and forwarding, peer-to-peer interactions, invoices, error handling, dispute resolution, messaging, and networks.

Therefore, any Lightning Network implementation, like LND, eClair, and c-lightning, must follow the BOLT standards.

Let’s briefly look at each of these implementations:

LND (Lightning Network Daemon)

LND, or Lightning Network Daemon, is a Lightning Network implementation developed by Lightning Labs.

Basically, it is software that allows users to create nodes on the Lightning Network, manage payment channels, send and receive transactions, and perform other necessary operations to participate in the Lightning Network.

LND is one of the most popular Lightning Network implementations, known for being robust and flexible, offering a variety of tools and APIs for developers to integrate the Lightning Network into their applications.

eClair

eClair is a Lightning Network implementation developed by ACINQ, a French technology company focused on Bitcoin network solutions.

That being said, eClair is designed to be an efficient and scalable solution for the Lightning Network, allowing users to create and manage nodes, establish payment channels, and send and receive fast and cheap off-chain transactions.

This implementation is also known for its robustness and developer-friendly approach, offering an API that makes it easy to integrate the Lightning Network into various services and applications.

Additionally, ACINQ also develops a mobile wallet called Eclair Mobile, enabling users to interact with the Lightning Network in a simple and intuitive way.

c-lightning

c-lightning is a Lightning Network implementation developed by Blockstream and is written in C, making it efficient and fast.

c-lightning allows users to set up nodes on the Lightning Network, manage payment channels, and perform off-chain transactions quickly and at a low cost.

Due to its flexibility and efficiency, c-lightning is a popular choice among developers and companies looking to implement the Lightning Network on their platforms.

Thus, standardizing the rules and procedures for the protocol ensures that different Lightning Network implementations can communicate and work together in consensus.

As the Lightning Network grows, BOLTs are updated and improved, and new Basis of Lightning Technology can be created if major changes in the protocol affect how all Lightning Network implementations work together.

Another interesting point is that BOLTs are designed to be compatible with improvements in the Bitcoin protocol (BIPs). This is important because it allows interoperability between different Bitcoin layers.

Layers of BOLT

There are several layers in BOLT, each defining a specific set of rules and protocols, as shown in the image below:

Layers of BOLT

Let’s understand each of them better, from top to bottom:

  1. Payment Layer: The highest layer of the network, which provides a reliable payment interface for applications. It defines the rules for using Hash Time Locked Contracts (HTLCs) to route payments between nodes, specifies the format of HTLC messages, and outlines the process for exchanging pre-images to release payments.
  2. Routing Layer: It defines the rules for creating payment channels between nodes, specifies the messages used for opening and closing channels, and defines the format of channel updates used to adjust the channel balance.
  3. Peer-to-Peer Layer: It includes protocols that nodes use to negotiate features, format messages, and encode message fields.
  4. Message Layer: It covers cryptographic transport protocols that secure messages on the Lightning Network.
  5. Network Connection Layer: It contains protocols that directly interact with the main Internet protocols (TCP/IP), overlay protocols (Tor v2/v3), and Internet services (DNS).

Now, let’s understand the BOLTs that have already been created.

Knowing and understanding all the BOLTs

Below is a list of all existing BOLTs, with links for you to view them directly on GitHub:

  1. BOLT #1: Base Protocol
  2. BOLT #2: Peer Channel Management Protocol
  3. BOLT #3: Bitcoin Transaction and Script Formats
  4. BOLT #4: Onion Routing Protocol
  5. BOLT #5: Recommendations for On-Chain Transaction Handling
  6. BOLT #7: P2P Node and Channel Discovery
  7. BOLT #8: Encrypted and Authenticated Transport
  8. BOLT #9: Assigned Feature Flags
  9. BOLT #10: DNS Bootstrap and Node Assisted Location
  10. BOLT #11: Invoice Protocol for Lightning Payments
  11. BOLT #12: Offers and Static Invoices

Wait, isn’t BOLT 6 (IRC Announcements) missing? I see you’re paying attention! BOLT 6 is not on the list because it was replaced by BOLT 7.

BOLT 1: Base Protocol

This BOLT defines message formats, data types, and peer connection management.

Below are the topics this standard covers:

BOLT 2: Peer Channel Management Protocol

Discusses channel operations such as opening, closing, and management.

Below are the topics this standard covers:

BOLT 3: Bitcoin Transaction and Script Formats

This one informs us how the necessary formats for on-chain Bitcoin transactions should be. It includes funding, commitment, HTLC transactions (Hash Time-Locked Contract), and key derivation.

Below are the topics this standard covers:

BOLT 4: Onion Routing Protocol

This standard describes the Onion Routing mechanism used for secure and private payment routing within the Lightning Network.

Below you can see the topics this rule covers:

BOLT 5: Recommendations for On-Chain Transaction Handling

It addresses channel closures in the good (mutual close), the bad (unilateral close), and the ugly (revoked transaction) ways.

Below you can check the topics this rule covers:

BOLT 7: P2P Node and Channel Discovery

This standard defines mechanisms for discovering nodes and Lightning channels on the network, including node announcements and channel updates.

Below are all the topics this rule covers:

BOLT 8: Encrypted and Authenticated Transport

It specifies the requirements for secure transport and message encryption between Lightning nodes.

Below are the topics BOLT 8 covers:

BOLT 9: Assigned Feature Flags

This standard establishes a framework for assigning feature flags to enable optional protocol extensions within the Lightning Network.

Feature flags allow network participants to indicate their support for new or experimental features and help coordinate the activation of these features across the network. These flags are represented by bits, where odd bits indicate optional features and even bits indicate mandatory features.

Therefore, feature flags are generally implemented through a consensus process in which network participants signal their support for a specific feature by adjusting a flag in the protocol messages they exchange. When a sufficient majority of participants signal their support, the feature can be activated on the network.

This feature flag system allows for a more gradual and coordinated implementation of new features, ensuring compatibility and minimizing network disruptions.

Additionally, it also allows for backward compatibility, as older implementations can still function without supporting the new features.

BOLT 10: DNS Bootstrap and Node Assisted Location

This one defines a method for Lightning Network nodes to find initial connections using DNS records and assisted node location services.

We use DNS for:

  • Bootstrap: Helping new nodes find other nodes on the network when they have no known contacts.
  • Assisted node location: Helping nodes discover the current network address of peers they already know.

Below are the topics this rule addresses:

BOLT 11: Invoice Protocol for Lightning Payments

This standard specifies the format and semantics of Lightning Network invoices, which are used to request and receive payments.

Below are the topics BOLT 11 covers:

BOLT 12: Flexible Protocol for Lightning Payments (Offers)

It addresses a limitation of BOLT 11.

For security reasons, BOLT 11 invoices can only be used once. BOLT 12 solves this by allowing the creation of new invoices in real-time without needing web servers (unlike LnURLs).

Besides generating invoices, offers in BOLT 12 are different because:

  • They are reusable, allowing for receiving payments from multiple people.
  • They can be used both to receive and request payments.

For users, this means being able to make reusable payment requests, having more privacy, and greater censorship resistance.

You can learn more about BOLT 12 on its official website.

Bolt12

Conclusion

Although the Lightning Network has grown significantly since 2018 and thousands of transactions are made monthly, many still consider it to be in an experimental phase and not ready to serve billions of people.

Indeed, there are some challenges for the mass adoption of Lightning.

First, the Lightning Network is more complex to use when users self-custody their balances compared to the first layer of Bitcoin.

Second, understanding channel opening and closing, as well as knowing how to run a Lightning node, requires some technical knowledge and involves risks. This is a big barrier for novices and makes them opt for custodial wallets, for example, where they do not need to deal with the technical issues happening on the protocol’s backstage.

However, developers are working tirelessly to reduce these friction points.

Remember, perfection takes time. As new tools are created, new Basis of Lightning Technology will emerge to improve all aspects of Lightning Network usability, from user experience to performance.

I hope this article has helped you better understand what BOLTs are in the Lightning Network.

Don’t forget to share it with friends and opt out!

Share on your social networks:

Written by
Image of author
Kaká Furlan

Founder of Area Bitcoin, one of the largest Bitcoin education projects in the world, she is a marketer, passionate about technology, and a full-time hands-on professional. She has participated in major Bitcoin conferences such as Adopting Bitcoin, Satsconf, Surfin Bitcoin, and Bitcoin Conference.

Ícone do X

Enjoyed this article? Donate some sats so we can grab a cup of coffee and keep writing. ☕