If you’re familiar with bitcoin, you’ll probably know how to create a public key with a static address and associated QR code that you could use or re-use to accept payments. While re-using addresses is not a recommended practice, it is a user experience people are familiar with and has practical use cases.
Plenty of people and institutions generate one public address and use that on their website or physical location as a method of managing payments or donations. It’s a simple and convenient way to accept payments, but not the most private as anyone can see all the transactions of that address.
When we move to second layers like lightning, this user experience is missing; there is no real way to have a reliable static QR code or public address, which has been a bother for some Lightning users. There are ways around it, like using a Lightning Email Address, but this service isn’t widely adopted by all wallets and users.
That could all change in the future if BOLT 12 rolls out across Lightning network instances.
What Is BOLT 12?
BOLT 12 (Basis of Lightning Technology 12), a newly-proposed Lightning Network specification for “offers,” a type of “meta invoice” designed by c-lightning developer Rusty Russell.
BOLT 12 offers is an attempt to achieve some of the core functionality that LNURL provides without requiring the use of a web server. Using BOLT 12 offer encodes the data necessary to reach a node to request an invoice to make a payment, either a node_id, or a blinded path (the last few hops in an onion route, pre-computed and encrypted) to that node using onion messages.
It also can encode a minimum amount for a payment, the currency being paid in, an expiry time and minimum/maximum quantity numbers (for purchasing multiple items).
This is all of the information necessary to fetch an actual invoice from the node that issued the offer. Someone who wants to pay an invoice does so over onion messages, one of the core features of BOLT 12.
Advantages of BOLT 12
It allows Lightning nodes to make a direct, end-to-end-encrypted connection between each other that does not involve a Lightning channel. Just like Lightning payments, these can be used to onion route messages. After obtaining an offer, a payer will use the information encoded in it to send an invoice_request message. The creator of the offer will then respond back with an actual invoice.
There is also support for generating unique per user offers that allow the receiver to request a payment from the creator of the offer, similar to LNURL’s withdrawal request feature. BOLT 12 invoices commit to a unique payer key — this can be used in the case of issuing refunds to prove you are the person who actually paid the invoice.
This can also be used in combination with the withdrawal offer to guarantee that only the correct person can succeed in getting an invoice paid by the creator, as opposed to whoever is able to get a copy of the offer. These two uses of offers effectively fulfill the same functionality as the invoice and withdrawal requests of LNURL, without the need to run a web server.
How BOLT 12 works?
A BOLT 12 “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: but with 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 (currency, vendor name, quantity limits, blinded paths to reach the vendor).
Improvements to anonymity
In cases where anonymity is concerned when it comes to the payee has to be preserved, an URL scheme has to be used which protects this anonymity.
An example of this would be an URL that points to a TOR hidden service. To not reveal the payee node ID to the payer, the payee can send an invoice to the payer, which has a partial onion route as a destination instead of a node ID.
The partial onion route ends at the payee, but it can start at some other node. All the payer has to do is prepend this partial route with extra hops, so the complete route starts at the payer. Note that this makes the invoice considerably larger; this would have been infeasible in BOLT #11.
Making lightning refunds easier
BOLT 12 also allows for convenient and potentially anonymous refunds since the communication channel can be kept open, and the payer can send a refund invoice through the same communication channel, making it far cheaper and easier for merchants to operate on Lightning. The ability to do HODL invoices and process refunds on your end at a fraction of the cost it takes to do it in traditional finance could be a major drawing card for further merchant adoption.
Learn more about Bolt 12
To get a better idea of how you can use Bolt 12, check out the following discussion on LN-URL vs Bolt 12
Sources:
If you would like to learn more about BOLT 12 and dive deeper down the rabbit hole, then we recommend checking out the following resources as part of your research.
Are you a bitcoin and lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Have you tried all the forms of Lightning payments? Which one do you prefer? Let us know in the comments down below.
