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 payment begins and during the actual payment. But why is this actually the case?
For a classic Bitcoin payment to a BTC address, the sender needs nothing more than the address (which is nothing more than a hashed representation of a public key). The sender's wallet can then simply create a new transaction output in which it formulates as a condition (unlock condition) that this output (this "coin") may only be moved with a matching signature to this public key. The recipient does not have to be online during the transaction, the sender only needs the recipient's address.
With Lightning, it works differently. To understand this, let's briefly review the process of a Lightning payment: A Lightning payment is routed through multiple routing nodes and their payment channels. In simple terms, the sender passes his satoshis to a routing node 1, asking it to pass them to routing node 2, and so on until the last node passes the sats to the recipient.
Each node passes on a little less than it receives, and this difference is the fee that the routing nodes are allowed to keep for their service. To ensure that all nodes along the route play by the rules, and that no one along the way simply keeps all the money without passing it on, the satoshis are "lured" by the original sender with a secret, i.e. tied to a condition.
This condition is chosen so that the nodes along the way cannot receive their satoshis until the money reaches the actual recipient.
How does it work?
To do this, the recipient wallet thinks up a random and unique secret, hashes it (see the "Hash function" infographic) and passes 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 to do so, and only then will the secret be visible to the other nodes along the route, and thus all along the route can only finally move the coins when the recipient has received the coins.
So to summarize: either the coins in all channels continue to move along the path, or nowhere coins move, 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 view.
We now know that we need to pass this hash (this hidden secret) to the sender before the actual transaction. This (passing this hashed secret) is exactly the main function of the Lightning Invoice. (Although there is also additional info in the Invoice, such as. Amount, Recipient Node ID, optional routing info, expiration date, as well as a Recipient Node signature, but the hash is the essential thing. (If you need more https://www.bolt11.org/ to view the contents of an Invoice).
For the security of the payment along the way (i.e. that none of the nodes along the route can simply take the coins without forwarding them), it is essential that no one knows the hidden secret until the payment has reached the recipient. For this reason, a Lightning Invoice can only ever be used once (because after that the secret is known). This means that for each new Lightning payment you have to ask the recipient again for a new Invoice.
In order to avoid having to ask the recipient manually 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 the LNURL protocol.
Essentially, LNURL is a web protocol, so it's simply a web server (a URL) that you can send a request like this: "Please give me a new, unused Lightning Invoice, because I want to send you money".
Thus, LNURL is not part of the actual Lightning core protocol, but a standard agreed upon by Lightning wallet developers to improve the usability of Lightning. LNURLs are also usually represented as QR codes. If 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 additionally encoded with an error-tolerant encoding 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 a Lightning Invoice, but simply a "https://" web address that a wallet can contact when 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 several other subprotocols 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 therefore makes sense to use them mostly only as QR codes. They are not intended for manual typing. However, in order to make it easier to remember or type in addresses manually, similar to e-mail addresses, a simplified representation of LNURLs was developed based on LNURL, which actually look exactly like e-mail addresses.
In the background, however, there is still simply an "https" web address, only it is simply defined by convention how this URL is structured.
So using the Lightning address as an example: username@domain.com
So a Lightning address looks like an email address, but is just a shortened representation for LNURL-pay web address. Everything else then works as with LNURL-pay.
An LNURL contains a web page URL. The protocol works over HTTP and requires that you own a domain name (or provide a Tor Hidden Service) and run a web server. This is not a limitation for custodial wallets or large service providers (because they usually already have a website), but in a private environment 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's not running over Tor). The recipient therefore usually learns where on the Internet the sender is located.
All this is not the case in the Lightning protocol. A lot of work has been put into privacy-preserving technologies there. Lightning uses a technique called "onion routing" that, like Tor, wraps a message in multiple encrypted layers, 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 path of that letter opens its envelope and finds only another addressed letter inside, the contents of which it does not know, and sends it on. Thus, no one on the transaction path knows the contents or the recipient of the message.
BOLTs (short for "Basis of Lightning Technology") is the name given to the Lightning specification documents (similar to BIPs for Bitcoin) and they can be viewed here on Github. So far, there are 11 Bolts. Bolt 11 describes the format of the Lightning Invoice. Bolt 12 would be the next document and is currently a draft. Bolt 12 describes an extension called "Lightning Offers" which is intended to provide a similar function as LNURL-pay currently does.
An Offer, like an LNURL, is reusable and static (a QR code can be used for many payments). Similar to an LNURL, an Offer contains the information where a wallet should go to receive a new fresh Invoice. However, the communication here is not done via HTTP, but like Lightning payments themselves, via onion routing. You don't need a domain name, a web server, and you don't have to reveal your IP address. Everything runs via the Lightning node and everything via the Lightning network.
In addition, it will allow for 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 wider adoption of LN.
The LNURL protocol family has the great advantage that it is very flexible in development, since these are protocols outside the Lightning core specification. This made it possible to develop very useful features very quickly in the past, which were very essential for the usability and usability of Lightning. Without LNURL, very many of today's Lightning projects and services would not (or not yet) exist. In addition, the limitations of LNURL are also perfectly ok in many use cases. If a customer is already communicating with an online store via HTTP, they lose nothing by also using 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/or situation in the future, but both protocols will probably coexist in the future as well.
With LNURL, new features can be implemented faster and things that are useful and meaningful for the core protocol will (slower, but sooner or later also) flow into the Lightning protocol anyway. So as long as Bolt 12 is still a draft and not yet implemented, it's better we use LNURL than not use Lightning at all.
Thanks for reading my contribution to this topic and until next time - yours Johnny.
%20(500%20x%20350%20px).png)
