Offers: Lightning's Native Experience, Everywhere

Offers is a draft specification (called a "BOLT") for Lightning wallets and nodes, with experimental support already in c-lightning.

We host an HTML copy of the latest text.

Experience

BOLT12 Offer

You scan a QR code, your wallet prompts you to pay it, just like BOLT11 invoices today (the QR code labelled BOLT11 Invoice).

But it could also prompt you to pay every day, hour, week or even minute. It might be in a different currency, say USD.

Or, it can offers to send you money, like for an ATM.

And unlike invoices, you can (and should!) reuse them: a static image on your web page, a QR code on your billboard. The BOLT 12 offer can be used by as many people as want to: the BOLT 11 invoice can only be used once, and is insecure if someone else tries to reuse it!

BOLT11 Invoice

How It Works

An "offer" has enough information for you to reach out and fetch a real invoice from the vendor, through the Lightning Network itself, just like it would send a payment: no web server needed. Your wallet then pays the actual invoice (or, for a "send invoice" offer, your wallet sends an invoice which the vendor pays, as an ATM or refund would use).

This means that offers can be much smaller than invoices, and contain more information (recurrence, currency, vendor name, quantity limits, blinded paths to reach the vendor).

Who

I am Rusty Russell, lead developer of c-lightning for Blockstream, which was the first implementation of the lightning network, and was the original chair of the Lightning Specification process. I also wrote the BOLT11 specification which defines lightning invoices used today, and so am very familiar with its limitations as the Lightning Network becomes ever more sophisticated.

Deployment

The draft was first posted September 2020, and revised heavily since. It was first implemented in c-lightning v0.9.3 released in January 2021, but since increased feedback and implementations come on board, it could change again.

DO NOT GET AN OFFER TATTOO UNTIL SPEC IS FULLY RATIFIED!

Onion messages are still in draft, too, though simple to implement: the current c-lightning implementation opens a direct connection to send onion messages if it needs to (bad for privacy unless you're using Tor!).

There's a REST API to decode offers, request invoices, and decode the invoices at bootstrap.bolt12.org; this includes extensive examples for usage. Obviously using this API exposes your information, but it makes wallet support trivial.

Technology

Offers are defined in the draft specification as BOLT12 (vs BOLT11 which defines invoices today); you can review the draft on GitHub

Onion Messages

Using the same onion mechanism we use to send payments, without the actual payment part. You can (and people do!) use fake payments to send messages today, but it's 3x slower and consumes far more resources on each hop.

Blinded Paths

This is supported in both onion messages and payments. It means the sender doesn't know where the message is going, but includes encrypted blobs given in the onion message. This is used for onion message replies, for example. It also allows offers to avoid revealing the node id of the vendor, if they want to.

Schnorr Signatures

BOLT 12 uses Schnorr signatures throughout, which make implementing multisig Lightning nodes transparently possible in future.

BIP 340

BOLT 12 uses x-only public keys (trivially backwards compatible for current nodes which use SEC-1 encoded compressed keys) which are slightly shorter, and uses the same signature scheme as Taproot.

Payer proofs

Your wallet creates a "payer key" when it requests an invoice: it can use this to prove to it owns the invoice (even the vendor can't fake this). This is used to claim refunds, for example (and with Blinded Paths you don't need to reveal your node identity to get your money back!).

Merkle Trees

Offers are technically a Merkle tree, which allows you to prove you made a payment, *without* revealing the details you don't want to.

Wire protocol

Offers, invoice requests and invoices are encoded using the exact same protocol as the Lightning Network uses today, just represented using the QR-code friendly bech32 character set.

Extensible

By using the compatibility schemes already used by the Lightning Network (feature bits, new fields) it's easy to expand for new uses in the future. There are already a few extension proposals!

Native

By using the Lightning Network to send messages, there's no need to run a web server or even deal with that: your lightning node does all the work of serving invoices for offers, and taking the money.

Examples

You can see some simple examples on the BOLT12 API Examples page.

Developing Offers

There are various people working on libraries and integration of offers: you can reach us on our Telegram channel.