BOLT 12 And LNURL: What Is The Future For Bitcoin’s Lightning Network?

BOLT 12 and LNURL seem to accomplish the same things for users of the Bitcoin Lightning Network. But what are the technical differences?

What is BOLT 12? Well, it is a lot of different features and moving pieces put together to accomplish multiple different things — static QR codes, modular invoices, privacy for the person receiving the payment.

But what is the whole package? It’s a way to have a single QR code, an “offer,” allow you to grab invoices from a node in a privacy preserving way, while also allowing for things like requesting that a remote node pay your invoice.

Now, anyone familiar with LNURL should already be thinking, “This sounds a lot like LNURL.” But for those of you who don’t know what LNURL is or how it works, here’s a quick breakdown.

What Is LNURL?

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 BOLT 12.

Three core pieces of the LNURL protocol are an authentication scheme, where a public key can be used to log in to a service, an invoice request scheme where a wallet can ping a server through a static QR code and retrieve an invoice, and a withdraw request scheme where a wallet can ping a server and request that the server pays an invoice provided by the wallet. Lightning invoices are much longer than on-chain Bitcoin addresses, the payment itself is already an interactive process requiring both parties to be online, so coordinating payment details interactively over a network connection makes sense.

The authentication protocol is effectively just the server providing a randomly generated number which the user’s wallet signs with a newly generated key. After the signed random value is received by the server, it saves the associated key to be used in 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.

The withdrawal request works by pinging the service, and receiving in response a description, a URL to send an invoice to, a random string (or deterministic to tie to an account or user), 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.

LNURL has smoothed over and improved much of the UX experience around using the Lightning Network, but it requires the use of a web server in order to be utilized. All of the requests and responses are handled through HTTP, and additional infrastructure beyond the Lightning node itself is required to handle these streamlined ways of coordinating and making payments. This is a perfectly reasonable requirement for any online service provider or merchant, who is realistically going to need a web server anyway to provide their service or products online. However, for a non-technical end user at home who simply wants such a streamlined experience, a street vendor, a physical shop or other users who do not already require the use of a web server, this can be a burdensome and potentially risky requirement.

What Is BOLT 12?

BOLT 12 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 BOLT 12. 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. 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.

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? What is the need for BOLT 12 if LNURL already exists? The key distinction is the web server. A web server requires running more infrastructure, a domain name, a TLS certificate and the expertise to manage these things.

While this is not an issue even worth mentioning for most businesses and services, as these things are needed to operate any online business in the first place, this is a big issue for your typical non-technical end user. It is not a reasonable expectation for a user to maintain extra infrastructure bolted on top of their Lightning node in order to have access to a streamlined and simple user experience. There is also the question of the centralization of DNS; a domain is not something that can ever be truly controlled by the owner.

These issues aside, both can co-exist. LNURL works just fine, and is already very widely adopted in the Lightning ecosystem, it is just not a realistic solution for users other than businesses or services. BOLT 12 as it is adopted can fill that gap, and provide the same streamlined user experience for end users at home 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.

Read More

What is BOLT 12? Well, it is a lot of different features and moving pieces put together to accomplish multiple different things — static QR codes, modular invoices, privacy for the person receiving the payment.

But what is the whole package? It’s a way to have a single QR code, an “offer,” allow you to grab invoices from a node in a privacy preserving way, while also allowing for things like requesting that a remote node pay your invoice.

Now, anyone familiar with LNURL should already be thinking, “This sounds a lot like LNURL.” But for those of you who don’t know what LNURL is or how it works, here’s a quick breakdown.

What Is LNURL?

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 BOLT 12.

Three core pieces of the LNURL protocol are an authentication scheme, where a public key can be used to log in to a service, an invoice request scheme where a wallet can ping a server through a static QR code and retrieve an invoice, and a withdraw request scheme where a wallet can ping a server and request that the server pays an invoice provided by the wallet. Lightning invoices are much longer than on-chain Bitcoin addresses, the payment itself is already an interactive process requiring both parties to be online, so coordinating payment details interactively over a network connection makes sense.

The authentication protocol is effectively just the server providing a randomly generated number which the user’s wallet signs with a newly generated key. After the signed random value is received by the server, it saves the associated key to be used in 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.

The withdrawal request works by pinging the service, and receiving in response a description, a URL to send an invoice to, a random string (or deterministic to tie to an account or user), 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.

LNURL has smoothed over and improved much of the UX experience around using the Lightning Network, but it requires the use of a web server in order to be utilized. All of the requests and responses are handled through HTTP, and additional infrastructure beyond the Lightning node itself is required to handle these streamlined ways of coordinating and making payments. This is a perfectly reasonable requirement for any online service provider or merchant, who is realistically going to need a web server anyway to provide their service or products online. However, for a non-technical end user at home who simply wants such a streamlined experience, a street vendor, a physical shop or other users who do not already require the use of a web server, this can be a burdensome and potentially risky requirement.

What Is BOLT 12?

BOLT 12 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 BOLT 12. 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. 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.

LNURL and BOLT 12 both accomplish the same general functionality, so what is really the difference between them? What is the need for BOLT 12 if LNURL already exists? The key distinction is the web server. A web server requires running more infrastructure, a domain name, a TLS certificate and the expertise to manage these things.

While this is not an issue even worth mentioning for most businesses and services, as these things are needed to operate any online business in the first place, this is a big issue for your typical non-technical end user. It is not a reasonable expectation for a user to maintain extra infrastructure bolted on top of their Lightning node in order to have access to a streamlined and simple user experience. There is also the question of the centralization of DNS; a domain is not something that can ever be truly controlled by the owner.

These issues aside, both can co-exist. LNURL works just fine, and is already very widely adopted in the Lightning ecosystem, it is just not a realistic solution for users other than businesses or services. BOLT 12 as it is adopted can fill that gap, and provide the same streamlined user experience for end users at home 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.

Feedzy