Bit of LNURL
LNURL
LNURL is a set of protocols which simplify payment interactions over the Lightning Network.
Here is a quick recap of an interaction so we can see where LNURL steps in. As always, we start with Alice and Bob. Alice is paying Bob for a coffee. Bob generates an invoice for Alice (the ol’ BOLT11) and gives Alice the invoice. Alice pays the invoice over the Lightning Network with her lightning wallet and receives the preimage proof-of-payment. She can hand the preimage to Bob who can verify it and hand her the coffee.
A few things to note about this ideal situation which are not always true. The big one is that Alice and Bob are both “online”, they are literally talking to each other irl! This hides two undefined steps in the lightning protocol: 1. Bob knows when Alice wants the invoice because she just asked him and he is waiting to serve her and 2. Bob knows how to give Alice the invoice, he just passes it to her (e.g. a printed QR code). But bitcoin is a digital native currency and might not always involve these “in real life” users. What if Bob wants to sell some digital art on the internet and accept lightning payments? Is he going to be sitting at his computer, just waiting 24/7 for someone in the world to stumble on his site and buy his art so he can generate them an invoice? And then how does he even send them the invoice?
Both of these steps are left undefined in the lighting payment protocol and it is up to the users how they want to go about it. What that also means is that the users get to decide just how easy and secure they want those aspects of the protocol to be. Ease of use and security can often be at odds with each other. LNURL covers these out-of-band protocols and makes some calls on the usability vs. security spectrum.
LNURL protocols require Bob to run a web server which implements LNURL and Alice to have a wallet app which also understands LNURL.
[Alice's LNURL Enabled Lighting Wallet] <--> [Bob's LNURL Webserver] <--> [Bob's Lighting Node]
High level components of LNURL
Let’s step through the digital art example, but now with one of the more popular LNURL specs, LUD-06 or “pay request”. Alice wants to buy some of Bob’s art. Bob’s website has a special link to buy his art which follows the “pay request” spec. The link tells Alice’s wallet app how to contact Bob’s web server in order to get a lighting invoice for the art. The web server turns around and gets an invoice from Bob’s node with the appropriate metadata and tosses it back to Alice’s wallet. The wallet can verify everything looks right and make the payment directly to Bob’s lightning node, getting the preimage in return. This can now be exchanged for the art. This is another out-of-band process, but could follow the something like an LSAT pattern.
The LNURL protocol allows Bob’s node to create invoices without him being “online” and also defines how the invoice is requested and sent: standard HTTP. This is pretty great considering how much of the world already uses HTTP, super easy to use and build on.
So what are the downsides?
For one, this is one more thing that Bob has to run, a web server, and another spot Bob needs to be willing to put credentials which have some authorizations to his node (e.g. invoice creation). This could be a large or small ask depending on Bob’s existing skills and infrastructure, but if you are selling things online this doesn’t feel too bad.
I think the implicit dependency on certificate authorities is the more interesting security tradeoff. If we compare the irl coffee payment to the digital art payment, there is a very clear middle-man in that LNURL diagram…the web server. And Alice’s wallet app assumes that this web server is a proxy for Bob’s node. How can it make this assumption? What if its actually Carol’s node that gets paid and not Bob’s? This is a specific example of a general problem with the internet today. How do you know the server you are talking to is the server it says it is? And today, this is solved with certificate authorities. The word authority doesn’t sound very distributed and it isn’t, the world of certificate authorities is very centralized. Ideally, the lightning users wouldn’t need this dependency, but this is security trade for the usability. And for relatively small lightning payments, I think its worth it.