heisenberg

bitcoin

Is LND (Lightning Labs) ruining the Lighting Network?

Krutus

Agree. And I personally think, that their market share is mainly because the fact, that LND is first/only choice in most of the "prepared solutions" like Umbrel, myNode, RaspiBlitz, Embassy, Citadel etc for plebs. 

Big players are more willing to use other solutions.

# Introduction
Most people think of the Lightning Network as a payment network for fast and cheap bitcoin transactions. But did you know that you can use your Lightning wallet to easily, securely and anonymously log in to certain services?

# Passwords
The most common authentication method on the Internet today is **username and password**. It's a decades-old concept that works quite well. But what are its drawbacks?

For convenience, users often choose **simple passwords** that can be guessed or cracked by brute force. Alternatively, they use the **same passwords** across multiple services, leading to the fact that if the password leaks, attackers can hijack identities on multiple platforms at the same time. They just try the same combination on other services.

# Lightning?
But what if we had an **alternative way** of logging in where we didn't need a username or password and the whole concept will be secure enough? Is that realistic?

The technology we will introduce in this post is the **LNURL-auth** protocol. LNURL is a set of protocols that extend the capabilities of the Lightning Network (we have already introduced one of them in the [post about the Lightning address](https://stacker.news/items/65872)) and specifically LNURL-auth takes care of logging.

And how do I imagine this in practice? Simple - you open a website supporting this technology, **scan a QR code** with your Lightning wallet (as if you were paying a traditional invoice) and you are logged in. It couldn't be simpler. But how does that work and is it even safe?

# Principle
An integral part of all Lightning wallets is the private key. As with on-chain bitcoin, this is a **random number** that you must not disclose to anyone and whose knowledge proves ownership of your bitcoins.

In practice, the website sends you random data that you sign with your **private key** and return a **pair** - a signature and a **public key**. The service then verifies the signature, and if it is correct, you have successfully confirmed your identity. This is done by knowing your private key, as only you own it and without it, a valid signature cannot be created.

In reality, you do not use the identical private key that you have as proof of ownership of your bitcoins, but depending on the URL of the website, a **different key** is derived for each website.

It may sound complicated for some beginners, but really it's just that your identity is **tied to your private key**, and as long as no one steals it, all you have to do is simply scan QR codes to log in to various services.

Your only concern is to **keep this key safe** - but for this you can usually use the well-known **seed-phrase** (12 to 24 words used to recover the master private key).

# Advantages and disadvantages
What are the **advantages** over the traditional login with a username and password?

- You don't need to create, remember or store any passwords.
- You don't even need to fill in a username, you just "scan QR code".
- Your password (in this case a private key) never travels over the network, so it cannot be intercepted.
- Your private key is derived differently for each service, so your identity cannot be correlated across multiple services (such as if you use the same email or username).
- Speed and simplicity.

What about the **disadvantages**?

- So far, very few services support this type of login.
- You must have a Lightning wallet that supports this technology.
- Whoever gets full access to your wallet has your identity.
- You are responsible for keeping your seed-phrase safe.

# Practice
From the preceding paragraphs, it should be clear that you will need a lightning wallet. In this particular case, I would strongly recommend one where you **actually own your private keys** (so called non-custodial), i.e. Phoenix or Breez for example. Or your own node via Zeus.

There is a support for this feature in BlueWallet as well, but since it is custodial **by default** (third party holds the private keys for you), I would not recommend it for this case. Neither Wallet of Satoshi nor Muun wallets support LNURL-auth technology yet.

You must then **back up** your wallet correctly, as you will lose your identity if you lose it. And of course, you should set up some kind of additional authentication when accessing your wallet (PIN, fingerprint, FaceID, etc.).

Some may find this way of storing your identity dangerous, but if a potential attacker gets into your phone and bypass biometrics to steal your identity from the wallet itself, he can steal your passwords from any password manager in the same way...

And that's it - you don't have to use the wallet itself to pay, you don't even have to have a single satoshi on it.

And where can you try Lightning login? For example here on Stacker.News :)

![LNURL-auth](https://platbybudoucnosti.cz/sn/lnurl-auth/lnurl_auth.png)

# Conclusion
Lightning authentication is an **interesting concept** that is very secure, anonymous, and user-friendly by simply scanning QR codes.

But the technology itself is still in its **very early days**, so we'll have to wait a while for wider support, both on the service and wallet side.

At the same time, however, it is also important to point out that there is no "real person identification" and anyone can create countless keys/wallets - i.e. identities. This issue must therefore be dealt with separately.

Anyway, you don't pay anything for the test, so **go ahead**!

# Addition?
Wait, that's it? If you're a bit of a geek and are interested in such concepts in depth, let's take a more technical look at the LNURL-auth protocol together. 

Every non-custodial wallet has a **master private key** (if not, we have a [solution](https://github.com/lnurl/luds/blob/luds/13.md) for that too). The derivation path **m/138'/0** contains the so-called **hashingKey**. We will put this together with the service URL into the HMAC function:

```
output = HMAC-SHA256(hashingKey, domain from URL string)
```

We take the first 16 bytes from the output and split them into 4 equally sized parts. This gives us a derivation path for the so-called **linkingKey**, i.e. a key that is unique for each service (URL):

```
linkingKey = m/138'/<part1>/<part2>/<part3>/<part4>
```

After scanning the QR code, the wallet decodes the bech32 and gets an HTTPS link, for example:

```
https://web.com?tag=login&k1=random_data&action=login
```

The **tag** parameter tells us that this is LNURL-auth and the **action** specifies the login (it can also be, for example, a registration, etc.). The very important parameter **k1** contains 32 bytes of random data that we need to sign with our **linkingPrivKey**.

After the user has agreed to the login dialog, the wallet responds with the same URL, only adding the **sig** and **key** parameters to it:

- **sig** = signed random data **k1** over the **secp256k1 curve** using the **linkingPrivKey** private key
- **key** = public key linkingKey

```
https://web.com?tag=login&k1=random_data&action=login&sig=signature&key=public_key
```

The service then verifies the signature and, if it is correct, assigns the user an identity based on his **linkingKey**, or alternatively creates a new one if it is a registration.

More details and specification itself:
- [https://github.com/lnurl/luds/blob/luds/05.md](https://github.com/lnurl/luds/blob/luds/05.md)
- [https://github.com/lnurl/luds/blob/luds/13.md](https://github.com/lnurl/luds/blob/luds/13.md)
- [https://github.com/lnurl/luds/blob/luds/04.md](https://github.com/lnurl/luds/blob/luds/04.md)


Lightning authentication (LNURL-Auth)

# Introduction
If you want to run your own Lightning node, there are currently three main implementations. In this slightly more technical post, we'll briefly introduce them and then we'll look at their market share, including how it can be obtained.
# Overview of implementations
Lightning Network is a payment network that allows anyone to create their own node implementation. To be compatible with the rest of the network, you just need to follow the [BOLT specification](https://github.com/lightning/bolts). However, this is very complex task and so the vast majority of users will use some already-made solution/implementation.

Today, we have three main implementations to choose from:
- **Lightning Network Daemon** (LND) from Lightning Labs
- **Core Lightning** (formerly c-lightning) from Blockstream
- **Eclair** from ACINQ

**LND** is definitely the most widely used Lightning implementation, which stands out for its simplicity and friendly API. LND is also part of the vast majority of ready-made solutions such as Umbrel, myNode or Raspiblitz, where it is often the only (or at least the default) implementation. Because of this, it has a large number of additional tools/extensions made by community and is suitable for beginners. However, advanced users or large nodes operators can use it also for sure. Recently, however, this implementation contained two vulnerabilities that slightly damaged its reputation.

**Core Lightning** is an alternative implementation and a "number two on the market" that is known for its stability and modular architecture. This means that you can install a lot of extensions in the form of standalone plugins in addition to the basic features. This makes it more suitable for slightly more advanced users who can customize it as they want.

**Eclair** targets more corporate clients, i.e. giant nodes with a very high number of channels and transaction volume. This implementation allows the node to be spread across multiple servers that distribute individual tasks among them using loadbalancing methods. Compared to previous implementations, there is a minimum of any community extensions.

# Cltv_delta parameter and gossip protocol
Within the lightning protocol itself, there is no "header" anywhere describing which specific implementation the node uses. Thus, it is unrealistic to find out the percentage distribution of node implementations **exactly**.

But we can make a relatively good guess. How? Each implementation has slightly different default values, and we take advantage of that. One of these values is **cltv_delta**. This is the number of blocks the node reserves for HTLC processing when forwarding a payment. In other words - it is the time difference between the outgoing and incoming HTLC.

The lower we set the **cltv_delta** value, the more risk we take, since after forwarding the payment towards the recipient (and getting **payment_preimage**) we have less time to contact the node towards the sender and get our funds. This may even end up in a force-close in the form of an on-chain transaction if this node is unavailable for long time, where this parameter then plays a crucial role.

On the other hand, a very high value means that the sender's resources may be locked for a longer period of time in case of problems, so this route is usually less preferred.

It should be clear from the text above that there is no **one correct value** (although the BOLT specification partially [defines it](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection)) and so each implementation has chosen it in its own way:

- LND has 40 blocks by default
- Core Lightning 34 blocks
- Eclair 144 blocks

The **cltv_delta** value is propagated through the network within the gossip protocol in the **channel_update** message along with information such as fees, minimum and maximum HTLC, etc.

# Practical part and finding the share of implementations
We will need a network graph - a list of all nodes and channels. This graph is public information and is maintained by each node. Unfortunately, there is no one correct graph. In fact, due to the way it is propagated, each node may have a graph slightly different from the others. Therefore, for these calculations, I used graphs from multiple nodes and averaged the results. The individual differences were below 1% for all parameters.

Next, we take advantage of the fact that most node operators do not understand the **cltv_delta** parameter and so they leave it in its default state. Thus, if the values of **cltv_delta** are **the same for all channels** of a given node, and at the same time this **value corresponds to one of the defaults**, it can be assumed that this is a given implementation.

If, on the other hand, **at least one** value of **cltv_delta** is different from the others or is not one of the default values, the node operator obviously modifies these parameters and cannot be relied upon. We discard such nodes from our statistics. Fortunately, this is only less than 7%.

![](https://platbybudoucnosti.cz/sn/lightning-implementations/EN_01.png)

To maximize the accuracy of the results, I excluded those channels that have not sent **channel_update** within the last 14 days, so according to the specification they should be considered outdated. Now is the time to create a script that will process the relevant data.

![](https://platbybudoucnosti.cz/sn/lightning-implementations/EN_02.png)

So what is the result? Exactly as expected, the LND implementation dominates. In other words, 91% of Lightning nodes have the **cltv_delta** value set to 40 blocks for all their channels, so this is most likely LND.

By the way, these results are **almost identical** to the [study](https://arxiv.org/pdf/2002.06564.pdf) from September 2020. Here, additional parameters were used, namely the minimum HTLC size and fees. The result was then calculated based on different weights for each parameter, with **cltv_delta** having the highest weight (75%). Since a lot of tools have recently been developed that automatically adjust these parameters, I did not include them in my calculations.

In addition, other interesting information can be retrieved from the graph, such as the average number of channels for a particular implementation or the average total capacity of a given node.

![](https://platbybudoucnosti.cz/sn/lightning-implementations/EN_03.png)

![](https://platbybudoucnosti.cz/sn/lightning-implementations/EN_04.png)

As can be seen above, the results support the description of the individual implementations from the beginning of this post. LND makes up the vast majority of the network due to the fact that it is part of most ready-made solutions, but these are primarily smaller nodes. In contrast, Eclair is on the other side of this ranking, as it powers, for example, the ACINQ node, which currently has nearly 3500 public channels and thousands more private ones. And somewhere in the middle stands Blockstream with its Core Lightning implementation.

# Conclusion
Finally, it should be noted that the above figures are **only an estimate**, because:
- Anyone can arbitrarily change the parameters and thus, purely theoretically, impersonate a different implementation, although there won't be many such cases.
- This data has been created based on **public** channels and nodes only, so it does not contain e.g. information about mobile nodes/wallets.
- There are other options for running nodes, such as building your own implementation using the Lightning Development Kit (LDK).
- At the same time, I used current default values - for example, LND in the past (until April 2019) used a value of 144 for **cltv_delta** (as does Eclair today), which was subsequently changed to the value described above. Extremely old implementations may therefore slightly bias the results, but even here I don't expect this to be a large sample.


Proportion of Lightning node implementations

How Lightning Address works

In LNURL-pay in general, the URL (encoded with bech32 encoding in QR code) can be anything, for example https://server.com/anythinghere.

In Lightning Address (subset of LNURL-pay), final URL is ALWAYS ".../.well-known/lnurlp/<username>".

My god... Encryption - converting plaintext to ciphertext :D

Small correction from my side - "...which is encrypted using bech32 encoding".

Encryption - converting text to text using a secret key. No one who does not know this secret key can decrypt the message.
Encoding - converting one form of text to another but without any key. It's just another representation of the same data and everybody can encode/decode.

bech32 is **not encryption, it's encoding**. Sorry for that.

More experienced users know, that nowadays you can send satoshis directly to Lightning Address in user@domain format. But how exactly does this work?

In this short article I would like to explain it to those who do not know it. At the same time, I will describe the basics of Lightning invoices and LNURL-pay protocol.

## Lightning invoices basics
Lightning Invoices are nowadays the standard for sending and receiving funds on the Lightning Network. If you want to receive some satoshis, you have to generate an invoice on your node/wallet. An invoice is nothing more than a text string (which starts with lnbc...) and contains, among other things, the recipient ID and the amount. There is actually more information but we won't go into that now. The invoice is most often shared using a QR code, which is nothing more than an image representation of the string described earlier.

Example:
![LN Invoice](https://platbybudoucnosti.cz/sn/invoice.png)

Lightning wallet then builds up several paths in the network to the recipient, ranks them from most advantageous and tries one by one until the payment is successful (or sometimes not).

However, Lightning invoices have certain limitations. Imagine you're a YouTuber and you want to embed a static QR code in your videos so your fans can send you donations. Each invoice has a expiration limit (usually 1 hour) and cannot be paid more than once. This is because some nodes learn a random number called payment_preimage when routing a payment, so it is not safe to pay one invoice multiple times, as fraud could occur. What to do about it? Let's use LNURL-pay!

## LNURL-pay basics
LNURL-pay is a standard, that allows us to create a static QR code, that can be paid multiple times. How does it work?

At its core, it is nothing more than a URL link to a web service using the HTTPS protocol (alternatively Tor), which is encrypted using bech32 encoding. A huge advantage in terms of user-friendliness is the fact that QR codes are indistinguishable to the human eye and therefore the average user does not need to know whether they are paying a regular invoice or LNURL-pay.

Example:
![LN Invoice](https://platbybudoucnosti.cz/sn/lnurl.png)

Payment procedure:
1. **User** scans the QR code (LNURL-pay) using his Lightning **wallet**.
2. **Wallet** decodes the QR code, then decodes the bech32 string, gets the URL and visits it using HTTPS.
3. **Service** responds to the wallet with a message asking for the amount (can be fixed).
4. **User** fills in the amount and sends this information to the **service**.
5. **Service** will return a classic Lightning invoice for the amount selected by the **user**.
6. **Wallet will pay the invoice**.

And that's it! So LNURL-pay is just a protocol that is used to negotiate (via the web server) what amount I want to generate an invoice for.

## Finally - Lightning Address
Now that we know the principles of invoices and LNURL-pay, understanding Lightning Address will be very easy. Remember, how we need to scan a QR code with LNURL-pay to get an initial HTTPS link?

With Lightning Address, you don't have to scan any QR code. For example, if your address is heisenberg@stacker.news, your wallet will translate that into URL https://stacker.news/.well-known/lnurlp/heisenberg. In other words, the link is not obtained from the QR code but is "compiled" from the Lightning Address. Your wallet visits this URL and the answer is well known LNURL-pay request, how much do you want to pay (point 3 above). Then the procedure is identical. And that's it!

## How to use it?
Many custodial wallet/solution nowadays generates a Lightning Address for you automatically, for example every user has address in format username@stacker.news. If you want to pay something to this address, just insert the address to the "invoice field" in your Lightning wallet. It's supported by majority of wallets. Another solution is to use tools hosted on your own Lightning node (like LNBits, LnMe or others) to be able to receive satoshis non-custodially.

**I hope you learned something new and let me know if you would be interested in similar articles.**