Skip to content

Understanding BOLT 11 vs BOLT 12

Comparing BOLT 11 vs BOLT 12

With a lot of improvements taking place in Bitcoin’s lightning network layer, understanding the differences between BOLT 11 vs BOLT 12 might be useful to help you to better understand how you can use them to their fullest potential.

Introduction To Bitcoin Lightning BOLTS

BOLT, which stands for “Basis of Lightning Technology”, refers to a set of technical specifications or protocols that define the rules and procedures for how the lightning network should operate. BOLT was first introduced in 2017 by a group of developers working on the Lightning Network, and since then, it has undergone several updates and revisions. The protocols are open source and available to anyone who wants to use or develop Lightning-related applications and services.

The BOLT specifications cover a wide range of topics related to the Lightning Network, including:

  1. Channel opening and closing procedures: These specifications define the rules for how payment channels can be opened and closed on the Lightning Network.
  2. Routing and forwarding rules: These specifications describe how payments can be routed through the network, and how nodes can forward payments to other nodes.
  3. Payment and invoice protocols: These specifications outline the rules and procedures for creating and sending Lightning invoices, and how payments can be made using these invoices.
  4. Error handling and dispute resolution: These specifications provide guidelines for how errors and disputes can be resolved on the Lightning Network, and how funds can be recovered in the event of a channel closure.

BOLT specifications are designed to be compatible with various Bitcoin Improvement Proposals (BIPs), which are technical proposals for changes or improvements to the Bitcoin protocol. This allows for a high degree of interoperability between different layers of the Bitcoin ecosystem, including the Lightning Network.

By standardizing the rules and procedures for how the Lightning Network operates, BOLT helps to ensure that different Lightning implementations can communicate and work together seamlessly. This helps to promote the growth and adoption of the Lightning Network, which has the potential to significantly improve the scalability and efficiency of Bitcoin.

Layers Of The BOLT Protocol

There are several layers to BOLT, each of which defines a specific set of rules and protocols. Here’s an overview of each:

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

Overall, BOLT provides a comprehensive specification for the Lightning Network, allowing different implementations to interoperate with each other seamlessly.

BOLT 11: Lightning Invoices

BOLT 11 is the first version of the BOLT protocol, and it is currently the most widely used protocol that includes a Lightning invoice and Keysend. A BOLT 11 invoice is a text string that consists of several parts, including the payment amount, the payment hash, and a set of metadata that describes the payment. The invoice is encoded in a way that allows it to be easily read and processed by both humans and machines.

An example of a lightning invoice is given below:

lnbcrt500u1p3luztppp5gaww3eg6ghmtvzp8qr6af2wgx7ndt4mt9kpx4jmtwax77kt7ft6sdqqcqzpgxqyz5vqsp5sl5uprqe0zfu5mkjuypwfykrqt0ka2ap7dq9m6grzyuzflhn8kzs9qyyssqqw4ckhutfyayzc0cgeffhshpf3ln2z8svdt77pkyju7j5c9kjfxrmd68cdq0xdlf3gn6k3m70lx84nt0xsrs0erq400d4t0vtze32pqqeg8reh

One of the key features of BOLT 11 is that it allows for a high degree of flexibility in the way invoices are constructed. For example, it is possible to include additional data in the invoice, such as a description of the payment or a payment memo. This makes BOLT 11 invoices highly customizable, which is useful for merchants who want to provide their customers with a personalized payment experience.

Another advantage of BOLT 11 is that it is backward compatible with older versions of the Lightning Network software. This means that it can be used with a wide range of Lightning wallets and nodes, which makes it a popular choice for developers who are building Lightning applications.

However, there are some limitations to the BOLT 11 invoice. One key limitation is that, unlike a Bitcoin address, a Lightning invoice can ONLY BE USED ONCE. Additionally, an invoice needs to be created by the receiver specifying a fixed amount before funds can be sent – there’s no flexibility for the sender to specify the amount and recipient of a payment.

Keysend

Keysend is actually not a part of BOLT 11, but is considered a Bitcoin and Lightning Improvement Protocol (bLIP) and it is the most common implementation of Spontaneous payment in Lightning in which an LN node can send payments to another LN node without first receiving an invoice.

With Keysend, the sender can specify the destination node’s public key and send a payment directly without an invoice. The sender chooses the hash preimage of the payment hash and encrypts it with the public key of the receiver, hence ensuring that only the receiver can decrypt the payment hash and claim the payment.

Keysend allows for a more streamlined payment experience, as it removes the need for invoice creation and scanning, and allows for spontaneous payments. However, it also has some potential downsides, as it could be used for spamming or other malicious purposes hence it has not been widely accepted in the Lightning Network.

BOLT 12: Offers

BOLT 12 is the latest version of the BOLT protocol, and it was introduced in 2020. It is designed to address some of the limitations of BOLT 11 and provide a more robust and flexible solution for Lightning payments.

BOLT 12 introduced alot of amazing features, one of which is Offers.

Offers also involve generating invoices, however Offers are different from lightning invoices in that:

  1. They are reusable and hence can be used to receive payments from as many people as possible
  2. They can be used to receive payment, and they can also be used to request payment.

How Offers Work

An “offer” has enough information that enables a user to fetch a real invoice from the vendor through the Lightning Network itself, just like it would send a payment: no web server needed. A wallet that scans an offer can then send a payment or, for a “send invoice” offer, the wallet sends an invoice that the other party pays. This means that offers can be much smaller than Lightning invoices and perform dual functions.

An example of an Offer invoice can be found below 👇:

lno1pg257enxv4ezqcneype82um50ynhxgrwdajx283qfwdpl28qqmc78ymlvhmxcsywdk5wrjnj36jryg488qwlrnzyjczlqs85ck65ycmkdk92smwt9zuewdzfe7v4aavvaz5kgv9mkk63v3s0ge0f099kssh3yc95qztx504hu92hnx8ctzhtt08pgk0texz0509tk

To create an Offer, the recipient first creates an invoice with the details of the payment request, such as the amount, the recipient’s public key, and any optional metadata. They then sign the invoice using their private key, creating a pre-signed invoice that can be shared with potential payers.

In summary, here are the major differences between BOLT 11 and BOLT 12

BOLT 11 BOLT 12
1) Invoices can only be used once to receive payment Offers can be used multiple times to receive payments. Does not expire
2) Invoices can also be used to receive payment and are generated by the receiver Offers can be used to receive payment and also request payment and can be generated by either the sender or receiver
3) It is already widely accepted in the Lightning network and is supported in LND, C lightning, Eclair e.t.c It is still a proposal and has only been integrated into C lightning as of the time of writing this article
4) Amount is a necessary field that needs to be passed An Offer invoice can be created without the amount
5) Invoice cannot be recurring or used for subscriptions Offers can be recurring and can be used to receive periodic subscription payments

Lightning remains one of the most exciting developments in Bitcoin which can facilitate millions of simultaneous payments. The advent of lightning invoices (and HTLCs) have made it easy for people to send and receive payments instantly, however alot of work still needs to be done to address the limitations that each new increment to the Lightning network brings, to ensure that we have a truly trustless, decentralized and yet effective second-layer protocol built on Bitcoin.

Thank You For Reading

If you found this article helpful, please consider sharing it, supporting one of these affiliates, or making a value for value donation so that we can continue to publish more Bitcoin-only content.