As you might know the Lightning network started back in March 2018 and serves as payment-layer to scale the transaction speed of the Bitcoin network and reduce the cost per transaction at the same time. Due to the lack of liquidity it was really hard to actually send payments at the beginning. While it became easier to participate in the network there are still challenges to solve in order to make it accessible for the broader mass. One of the main problems is the need to create an invoice each time you want to receive a payment. From a UX perspective this is absolutely horrible. LNURL and BOLT12 try to solve some of these issues which I will try to explain in the following part.

LNURL: What exactly is that?

LNURL is a stack of simple protocols for coordinating information needed to make payments over the Lightning Network using HTTP. The full list of LNURL protocol pieces can be found here, but I'm just going to go into a few core uses that overlap with BOLT12.
The three core features of the LNURL protocol are defined as:

• LNURL-auth, where a public key can be used to log in to a service
• LNURL-pay, where a wallet can ping a server through a static QR code and retrieve an invoice
• LNURL-withdraw, where a wallet can ping a server and request that the server pays an invoice provided by the wallet

For using the authentication protocol the server provides a randomly generated number which the user's wallet signs with a newly generated key. After the server retrieves the signed randomly generated number the key gets saved and can be used for future logins.

The invoice request functionality is a way to provide information to a user about a payment they wish to make in a format that is not an invoice. This provides a description of the payment, the minimum and maximum amount the service expects to be paid, and a URL for the wallet from which to request an actual invoice. From here, the wallet displays this information to the user, allowing them to set a final amount and request an invoice. After sending the invoice request and receiving one back from the server, the wallet verifies that the amounts match what the user set and pays the invoice.
(Note: This feature is already available if you're using Phoenix, Wallet of Satoshi or BlueWallet. Muun does not support it as of now [December 2022])

The withdrawal request works by pinging the service, and receiving in response a description, a URL to send an invoice to, a random string, and a minimum amount and maximum amount that can be withdrawn. After filling in the appropriate value, the wallet returns an invoice to the server, and if it is valid and within the amount parameters, the service pays the invoice. The LNURL authenticate protocol can be used in addition to this to ensure that only the intended user can successfully withdraw using the LNURL link. Common use case would be if you want to withdraw your sats from a lightning service such as the lntipbot here on reddit or the lntxbot on Telegram.

​

BOLT12: Why do we need it?

The term "BOLT" is the acronym for "Basis Of Lightning Technology". You can compare these to the BIPs (Bitcoin Improvement Proposals) which are design documents for introducing features or information to Bitcoin. The BIP, as amended, has since become the standard way of formally communicating ideas about potential Bitcoin improvements.
As mentioned at the beginning of this post there are some UX flaws which need to be addressed. To understand the problems BOLT12 attempts to solve it is mandatory to have a look at the current standard which is used to create invoices, BOLT11.

Invoices generated by the BOLT11 standard consist of three main components:

• The destination where the payment is supposed to be sent to. (Public key of the node)
• The amount which is about to be transferred
• A hash which represents the payment secret
  

The main problem of BOLT11 invoices is that they can only be used once and therefore need to be created in realtime. The creation of the invoice leads to the publishing of the payment secret and is therefore unsecure. If you would create an invoice with the same secret, someone could fraudulently request money due to the fact that the secret is known. This makes the usage of QR-code invoices for donations or other use cases impossible.

What is BOLT12?

BOLT12 offers an attempt to achieve some of the core functionality that LNURL provides without requiring the use of a web server. An 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 BOLT12. It allows 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. BOLT12 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.

What's best?

Both LNURL and BOLT12 enable a more user friendly way for paying or getting paid on the Lightning network. While LNURL sits on the application level, BOLT12 provides a solution on proctocol level, where the new offers do neither require a web server, TLS-certificates nor a domain and provide a higher level of protection than LNURL. Using blinded paths the BOLT12 offers allow the confidentiality of the node-id, which additionally enriches the privacy. It's important to say, both solutions can exist simultaneously. While online shops and other service providers operate a web server anyway, LNURL is a good add-on. BOLT12 mostly addresses the endusers and offers a more convenient way to interact with the Lightning network.