Before doing a deep-dive on the more topical BOLT 12 and how future payments could help improve payments on lightning, we should first explain how payments currently work with BOLT 11.

Bitcoin Address vs. Lightning Invoice

BOLT 11 is the formal definition on how to pay people over lightning, similar to how transaction outputs and address types define how bitcoin is sent over the Bitcoin blockchain. When you make payments on (layer-one) Bitcoin you generate and share an address to the payee. With (layer-two) Lightning the difference is, the payee requests an invoice from the payer, and that invoice expires if it’s not paid within a specified time.

Bech32 Encoding for QR Codes

From a user experience standpoint, this means you’re presented with a unique QR code containing a BOLT 11 Invoice at the point of payment instead of providing one. The invoice is created with the same bech32 encoding that was previously used in SegWit, which was designed to error correction when addresses are typed and make the robot vomit of QR codes compact.

You’ll notice that the invoice is much larger than the address because bech32 in SegWit encodes a simple hash. And for Lightning Network usage bech32 encodes an entire payment invoice, which is why the invoice QR codes also look larger and more complex.

Decoding BOLT 11 Lightning Invoice Data

When decoding the BOLT 11 invoice we have two parts:

1. The Human-Readable Data

2. The Machine Data

2.2 The Tagged Fields

Defined tags are optional fields for adding a payment hash, invoice description, expiry time, public key of the payee node, a fallback bitcoin “onchain” address, extra routing information for routing to an unannounced channel, payment metadata, a payment secret to prevent probing by other nodes, and more. Each field has its own: type, data_length, and data section for formatting purposes. But knowing the details of all this data is not as important as understanding the motivation for updating this.

Problems With BOLT 11

There are some problems with BOLT 11, and particularly bech32. Bech32 encoding was used because it was familiar to SegWit, but it makes invoices that are so large and clunky to send inside the lightning network it’s not the best user experience. Secondary to that, the encoding was found to have mutation issues meaning that it will have to be replaced anyway. In a future post, we’ll cover more about BOLT 12 offers and how developers can fix some of the existing issues with BOLT 11 invoices.

Aside from BOLT 11, there are other optional ways you can pay people over lightning using Keysend, LNURL, MMP / AMP, and with Lightning address, which we will cover in future deep dives as well.