What is Bolt12 and why this matters

How Bolt 12 improvement can impact the Usability of the Lightning Network

Did you ever hear about BOLT 12? I think you did. BOLT 12 is an upgrade to the Lightning Network that aims to significantly enhance the user experience compared to the current BOLT 11 standard and offer advantages over solutions like LNURL. It represents a vision for how Bitcoin payments on the Lightning Network could function in the future.

What is BOLT 12?

BOLT 12 introduces the concept of "offers" as a preliminary step to payment requests, moving away from the one-time use invoice system of BOLT 11. These offers contain the necessary information for a wallet to communicate with a Lightning node to coordinate payment processes. Key characteristics of BOLT 12 include:

• Reusable Payment Requests: Unlike BOLT 11 invoices that can only be used once, BOLT 12 offers are designed to be reusable. This allows for scenarios like displaying a static QR code for a tip jar that can receive multiple payments without needing to generate a new invoice each time.

• Enhanced Receiver Privacy: BOLT 12 incorporates features like route blinding, enabling receivers to accept payments more discreetly and securely, which is beneficial for individuals who require anonymity.

• Increased Censorship Resistance: Through the use of onion messaging, BOLT 12 can help users in censorship-heavy environments to receive donations or payments without their IP address being easily blocked.

• Dual Functionality: BOLT 12 offers can be used not only to receive payments, similar to BOLT 11 invoices, but also to request payments. This opens up possibilities for different payment flows.

• Simplified QR Codes: Because a BOLT 12 offer primarily needs to embed information about a Lightning node rather than specific payment details, the resulting QR codes can be much simpler than those generated for BOLT 11 invoices.

• Native Network Communication: BOLT 12 aims for communication and coordination between Lightning nodes to happen natively on the network using Onion Messages, which are similar to the Onion Routing protocol but without the payment aspect. This intends to allow "Offers" to function without reliance on external servers.

• TLV Encoding: BOLT 12 offers and invoice_request messages are encoded using the Type-Length-Value (TLV) format described in BOLT 1, providing flexibility and extensibility for future upgrades.

• Payment Proof Enhancement: Unlike BOLT 11, BOLT 12 enables the payer to prove they were the ones who made the payment. Additionally, in case of disputes, payers can reveal only part of the invoice to preserve some privacy.

Benefits Compared to LNURL

• Native on-chain operation: A significant advantage of BOLT 12 over LNURL is that it aims to perform communication and coordination natively on the Lightning Network itself, utilising Onion Messages. LNURL, on the other hand, typically relies on communication over HTTP with external web servers to generate invoices or handle other requests.

• Potentially Enhanced Privacy: By using Onion Messages, BOLT 12 may offer improved privacy compared to LNURL, which often involves interactions with web servers that could potentially track or log requests.

• Direct Lightning Network Interaction: BOLT 12 facilitates direct communication between Lightning nodes for requesting invoices, which is a core function of the Lightning Network.

Benefits Compared to BOLT 11

• Reusability: The key benefit of BOLT 12 offers over BOLT 11 invoices is their reusability for receiving multiple payments. BOLT 11 invoices are single-use only.

• Requesting Payments: BOLT 12 offers can be used to both receive and request payments, providing more flexibility than BOLT 11 invoices, which are solely for receiving payments initiated by the payer.

• Static Payment Codes: The potential for static QR codes with BOLT 12 simplifies the payment process for recurring payments or tips, eliminating the need for constant invoice generation.

• Optional Amount: BOLT 12 offers can be created without a specific amount, allowing the payer to determine the amount, whereas BOLT 11 invoices typically specify a fixed amount by the receiver.

• Recurring Payments/Subscriptions: BOLT 12 is designed to support recurring payments and subscriptions through the use of reusable offers, a feature absent in BOLT 11.

BOLT 11 remains at the moment the most widely used protocol for Lightning invoices. However, BOLT 12 holds significant promise for improving the usability and flexibility of the Lightning Network in the future.