BOLT 12 And LNURL: What Is The Future For Bitcoin’s Lightning Network?
What is BOLT 12? It is a combination of many features and moving parts that accomplish multiple things. These include static QR codes, modular invoices, and privacy for the person who receives the payment.
But, what’s the whole package? It allows you to have one QR code, an “offer,” that allows you to get invoices from a node. This privacy-preserving method also allows you to request that a remote node pay your bill.
Anyone who is familiar with LNURL will already be thinking “This sounds a lot similar to LNURL.” But, for those who don’t know the basics of LNURL or how it works here’s a quick explanation.
What is LNURL?
LNURL consists of a set of simple protocols that coordinate information necessary to make payments over 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 BOLT 12.
Three core components of the LNURL protocol include an authentication scheme where a public key is used to log into a service, an invoicing request scheme where a client can ping a remote server using a static QR code to retrieve an invoice, and finally, a withdrawal request scheme where a client can request that a server pay an invoice it has received from the wallet. Lightning invoices are longer than on-chain Bitcoin addresses. The payment itself is interactive and requires both parties to be online. It makes sense to coordinate payment details over a network connection.
The authentication protocol is essentially the server providing a random number that the user’s wallet then signs with a new key. The server receives the signed random value and saves the key for future logins.
The invoice request functionality allows users to request information about a payment that they wish to make, but not an invoice. This includes a description of the payment and the minimum and maximum amount that the service expects to receive. The URL to the wallet is also provided to request an invoice. The wallet displays this information to the user. It allows them to enter a final amount and request an invoicing. After receiving an invoice from the server, the wallet verifies the amount and pays the invoice.
The withdrawal request is made by pinging the service and receiving a response with a description, URL to send an invoice, a URL to send it to, a random string or deterministic to tie to a user or account, and a minimum and maximum amount that can withdrawn. After entering the required value, the wallet sends an invoice to the service. If it is valid and within the specified amount parameters, the service will pay the invoice. To ensure that only the intended user can withdraw using the LNURL link, the LNURL authenticate protocol may be used.
LNURL has improved the user experience with the Lightning Network. However, it requires a web server to be used. All requests and responses are handled via HTTP. Additional infrastructure is needed to support these simplified ways of coordinating payments and coordinating requests. This is a reasonable requirement for any merchant or online service provider who will likely need a web server to offer their products or services online. This can be problematic for non-technical users at home who want a simplified experience.
What Is BOLT 12?
BOLT 12 is an attempt to achieve the core functionality of LNURL without the need for a web server. An offer encodes data that is required to reach a node in order to request an invoice. This could be either a node_id or a blinded (the last few steps of an onion route, pre-computed, encrypted, and sent) to that node using onions messages. It can also encode the minimum amount, the currency to be paid in, an expiry date, and minimum/maximum quantities (for multiple items).
This information is necessary to retrieve an invoice from the node that issued it. Someone who wants to pay an invoice does so over onion messages, one of the core features of BOLT 12. It allows nodes to establish a direct, encrypted, end-to–end connection between themselves that does not require a Lightning channel. These can be used to send onion route messages, just like Lightning payments. A payer will use the information in an offer to send an invoice_request. The offer creator will then send an invoice.
The creator of the offer can also generate unique per-user offers that allow the receiver, in a similar fashion to LNURL’s withdrawal request feature, to request payment from him. BOLT 12 invoices promise a unique payer key. This can be used to issue refunds to prove that you are the one who paid the invoice. This can be combined with the withdrawal offer to ensure that the invoice is paid only by the creator.
These offers can be used in conjunction with the withdrawal request and invoice of LNURL.
LNURL Or BOLT 12? It’s All About Tradeoffs
LNURL and BOLT 12 both accomplish the same general functionality, so what is really the difference between them? If LNURL is already available, what’s the point of BOLT 12? The web server is the key distinction. A web server requires more infrastructure, a domain, a TLS certificate, and the expertise to manage it.
While this is not a major issue for most businesses or services, it is important for non-technical users. It is unreasonable to expect a user to have additional infrastructure installed on top of their Lightning node to provide a simple and seamless user experience. The centralization of DNS is another issue. A domain cannot be controlled by anyone.
These issues aside, they can co-exist. LNURL works well and is widely used in the Lightning ecosystem. However, it is not an ideal solution for users who are not businesses or service providers. BOLT 12, as it is being adopted, can fill this gap and provide the same streamlined experience for home users who are not businesses.
Both solutions accomplish roughly the same thing for two different classes of users, and that is OK.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.