A lot of progress is being made to improve the user experience for those who would like to buy a cup of coffee with their bitcoin. For the longest time most new developments were happening in infrastructure projects such as nodes, exchanges, trading, hardware and software wallets. Now the Lightning Network has brought the focus of many developers back to the end-user, including a resurgence in mobile wallet development with several new Lightning-first wallets.
In the early days a high-level of knowledge was required to use the Lightning Network. But this is no longer the case. There are already some solid, newbie-friendly wallet apps available:
- Phoenix by ACINQ - easy, non-custodial
- WalletOfSatoshi - very easy, but custodial!
- BLW (Bitcoin Lightning Wallet) - non-custodial, medium complexity
- Breez - non-custodial
One of the latest developments that is helping to improve the usability of the Lightning Network is LNURL - a side channel communication protocol to smooth over some of the remaining UX problems. LNURL is a set of subprotocols each with a specific UX flow designed to be simple and easy to implement.
Withdrawals
One pain point with the Lightning Network has been the need to generate a new, unique invoice for every payment that you would like to receive and then somehow give this invoice to the service that you are using so that it can be paid. One real-world example is a web-based paywall service that accumulates satoshis via Lightning Network on your behalf. Once in a while you might want to manually withdraw your satoshis to your own wallet. To do this you would need to first generate an invoice for the exact number of satoshis and then copy/paste that invoice into your computer's browser. But if your wallet is on your phone, this can be an annoying experience.
Enter the lnurl-withdraw subprotocol. With a service that supports it, the end user simply scans a single QR code and the service communicates with an LNURL HTTP server to facilitate the payment process via the Lightning Network. The user doesn't need to manually generate invoices or count satoshis - their wallet and the web service can do all of that in the background.
Smooth, New Real-World Applications
This improved user experience is a perfect fit for many applications such as an offline Lightning Network ATM, simplified withdraw processes from exchange accounts, withdrawing change from a PoS terminal, and more.
Static Payment QR Codes
Another popular subprotocol is lnurl-pay. This one enables static QR codes that can be printed and re-used many times. A common example would be a printed sign that contains a QR code for donations. The lnurl-pay subprotocol allows the receiver to specify a range (min/max) for the accepted payment amounts. When the end-user (payer) scans the QR code, they are presented with a dialog that asks how much they want to pay. They choose the amount, confirm the payment in their app, and then their app communicates with an LNURL server to complete the payment via the Lightning Network.
Street Artists Beware!
Those QR-encoded donation addresses are destroying your privacy. Anyone who scans the QR code can see your address and its complete transaction history. One huge advantage to lnurl-pay QR codes is privacy. The payer's app only sees a decoded URL and min/max parameters. They won't be able to see your transaction history or how much money you've received.
Authentication
Growing in popularity with bitcoin and Lightning Network developers, lnurl-auth allows service operators to provide a new method for authentication, authorization, and login.
A special linkingKey can be used to login user to a service or authorise sensitive actions. This preferrably should be done without compromising user identity so plain LN node key can not be used here. Instead of asking for user credentials a service could display a "login" QR code which contains a specialized LNURL.
Though part of the LNURL specification, lnurl-auth doesn't actually touch the Lightning Network. It uses your bitcoin wallet's existing seed to generate a unique signing key for each website with which you authenticate. The protocol can be used as a 2FA option or as a replacement for email/username + password login.
The protocol dictates that the user's app should deterministically derive a "hashing key" and use that to derive a unique linking key for each service with which the user attempts to authenticate. Privacy of the user is protected because the user's app provides a unique public key to each service. App developers are encouraged to follow the derivation scheme defined in the specification to allow for portability between apps.
Open Channel Request
Probably the least popular of the subprotocols, lnurl-channel allows an end-user to request that a channel be opened to their node.
Suppose user has a balance on a certain service which he wishes to turn into an incoming channel and service supports such functionality. This would require many parameters so the resulting QR may be overly dense and cause scanning issues. Additionally, the user has to make sure that a connection to target LN node is established before an incoming channel is requested.
Resources and Tools
If you'd like to add support for LNURL to your own app or service, have a look at this comprehensive list for tools, libraries, and other services that already support it.
During the lockdown earlier this year, I created lnurl-toolbox - a browser-based tool to test mobile and browser-based implementations of the LNURL protocol. If you'd like to try it out for yourself, I recommend the BLW wallet app (linked above) because it has the most comprehensive LNURL support.
