Unlike paying on-chain, i.e. sending Bitcoin to a Bitcoin address, a payment process via the Lightning Network is always an interactive process. The two LN nodes (payee and sender) must interactively exchange information before the start and during the actual payment. But why is that actually the case?
For a classic Bitcoin payment to a BTC address, the sender requires nothing more than the address (which is nothing more than the hashed representation of a public key). The sender's wallet can then simply create a new Transaction Output, in which it states as a condition (unlock condition) that this output (this “coin”) may only be moved to this public key with a suitable signature. To do this, the recipient does not have to be online during the transaction; the sender only needs the recipient's address.
It works differently with Lightning. To understand this, let's briefly discuss the process of a Lightning payment: A Lightning payment is forwarded via several routing nodes and their payment channels. Put simply, the sender gives his Satoshis to a Routing Node 1 Further, with the request that they send them to Routing Node 2 passes on, etc. until the last node passes on the sats to the recipient.
Each node passes on a little less than it receives, and this difference is the fees that the routing nodes are allowed to keep for their service. To ensure that all nodes along the route also play by the rules and that no one on the way simply keeps the money completely without forwarding it on, the Satoshis are “lured” by the original sender with a secret, i.e. subject to a condition.
This condition is selected so that the nodes along the way can only receive their Satoshis when the money has reached the actual recipient.
How does that work?
To do this, the recipient wallet comes up with a random and unique secret, hashes it (see “Hash Function” infographic) and transfers this hash directly (i.e. outside the Lightning Network) to the sender. The sender wallet now designs its transaction in such a way that only the person who knows the secret behind this hash can take the coins and sends them on their way through the Lightning Network.
This ensures that all nodes along the route can only move the coins when the payment arrives at the recipient, because if the recipient wants to take the sats, he must reveal the secret behind the hash and only then is the secret visible to the other nodes along the way and therefore everyone along the way can only finally move the coins when the recipient has received the coins.
In short: either the coins continue to move along the way in all channels, or there are no coins moving anywhere, there is nothing in between. The whole process is atomic (all or nothing).
To learn more about the Lightning Network, check out this blog post on.
We now know that we must hand over this hash (this hidden secret) to the sender before the actual transaction. Exactly that (handing over this hashed secret) is the main function of Lightning Invoice. (There is also additional information in the invoice, such as. Amount, recipient node ID, optional routing information, expiration date, and a recipient node signature, but the hash is the essence. (If you have more about this https://www.bolt11.org/ to view the contents of an invoice.)
For the security of the payment on the way (i.e. that none of the nodes along the route can simply accept the coins without forwarding them), it is essential that no one knows the hidden secret before the payment has reached the recipient. For this reason, a Lightning Invoice invariably can only be used once (because the secret is known afterwards). This means that for every new Lightning payment, you have to ask the recipient again for a new invoice.
In order not to have to manually ask the recipient for a new invoice every time, developers have developed a protocol based on HTTP (i.e. outside the actual Lightning network) that automates this exchange of Lightning invoices. This is that LNURL protocol.
LNURL is essentially a web protocol, i.e. simply a web server (a URL) to which you can send a request of this type:”Please give me a new, unused Lightning Invoice because I want to send you money”.
LNURL is therefore not part of the actual Lightning core protocol, but a standard that Lightning wallet developers have agreed on to improve the usability of Lightning. lnURLs are also usually represented as QR codes. When you look at the text in such a QR code, it always starts with “lnurl” and not with “https”. This is because the web address is also encoded using an error-tolerant coding method (with checksum), namely “bech32” (which is also used for Segwit Bitcoin addresses).
With such LNURL QR codes, it is now possible to create static, reusable QR codes that can be used for multiple payments. So this QR Code does not contain a Bitcoin address or Lightning Invoice, but simply an “https://” web address that a wallet can contact if it wants to receive a new fresh LN Invoice.
For the sake of completeness, it should be noted that this is only a partial application of the LNURL protocol, namely LNURL-Pay, there are a few other sub-protocols that also use LNURL, such as lnURL-auth for login, or lnURL-withdraw if you want to receive instead of send.
LNURLs are usually long and not intuitively human-readable. It makes sense to use them usually only as QR codes. They are not intended for manual typing. However, in order to make it easier to manually remember or type in addresses, similar to e-mail addresses, based on LNURL, a simplified representation of LNURLs was developed, which actually look the same as e-mail addresses.
However, there is still simply an “https” web address in the background, but it is simply defined by convention how this URL is structured.
So using the Lightning address as an example: username@domain.com
A Lightning address therefore looks like an email address, but is only an abbreviated representation of LNURL-Pay web address. Everything else then works just like LNURL-Pay.
An LNURL contains a website URL. The protocol works over HTTP and requires you to own a domain name (or provide a Tor hidden service) and operate a web server. This is not a restriction for custodial wallets or large service providers (because they usually already have a website), but in the private sector this can be a hurdle (not every small private user runs a website). In addition, as a user (sender) of LNURL, you disclose your IP address to the web server every time (if it is not currently running via Tor). The recipient therefore usually finds out where the sender is on the Internet.
None of this is the case in the Lightning Protocol. There, a lot of work was put into privacy-friendly technologies. Lightning uses a technique called “onion routing,” which wraps a message into several encrypted layers similar to Tor, much like a letter that you put in a letter, that you put in a letter that you put in a letter. Each station along the way of this letter opens its envelope and only finds another addressed letter, the content of which it does not know and forwards it. As a result, no one on the transaction path knows the content or recipient of the message.
BOLts (short for “Basis of Lightning Technology”) are the Lightning specification documents (similar to BIPs with Bitcoin) and they can here can be viewed on Github. There are 11 Bolts so far. Bolt 11 Describes the format of the Lightning Invoice. Bolt 12 That would be the next document and is currently still a draft. Bolt 12 describes an extension called “Lightning Offers,” which should offer a similar feature to LNURL-Pay currently.
Like an LNURL, an offer is reusable and static (a QR code can be used for many payments). Similar to an LNURL, an offer contains information about where a wallet should go in order to receive a new fresh invoice. However, communication here is not via HTTP, but, like Lightning Payments itself, via onion routing. You don't need a domain name, a web server, and you don't have to reveal your IP address. It all runs on the Lightning Node and everything runs on the Lightning Network.
In addition, it will enable other features, such as regularly recurring payments (standing orders), optional payer proofs (optional proof of who paid, if desired), and other features that should benefit the further distribution of LN.
The LNURL protocol family has the big advantage that it is very flexible in development, as these are protocols outside the Lightning Core specification. In the past, this made it possible to develop very useful features very quickly, which were very essential for the usability and usability of Lightning. Without LNURL, many of today's Lightning projects and services wouldn't exist (or don't yet). In addition, the restrictions of LNURL are completely okay in many applications. If a customer already communicates with an online shop via HTTP, they lose nothing if they also use LNURL over HTTP.
At the same time, however, it is important to be able to provide all these functions for self-hosted wallets without a service provider and without a web server. It will therefore probably not be an either/an or in the future, but both protocols will probably continue to coexist in the future.
With LNURL, new features can be implemented faster and things that are useful and useful for the core protocol will be incorporated into the Lightning protocol anyway (slower, but sooner or later too). So as long as Bolt 12 is still a draft and not yet implemented, it's better we use LNURL than not to use Lightning at all.
Thank you for reading my post on this topic and until next time - yours johnny.
