The Lightning Network FAQ

[cygan]

as i promised a few days ago, here are 4 more slides about splicing on the lightning network

[darkv0rt3x]

@Cygan, maybe you could also, at the end, gather all the illustrations, compact them and make them available somewhere for people to be able to download and keep for themselves. And eventually consult them whenever they need. Because doing things as of onw, we will have many illustrations spread along probably many pages here in the forum!
Keep bringing the illustrations. xD

[cygan]

@darkv0rt3x i had the same thought yesterday, while i was writing yesterday's post. you're right, there will be a little 'confusion' at some point and you'd have to go back quite a few pages to see all the slides (i think there will be 16 in total).
my thought is that i might open an extra thread for this topic so that all the information can be collected there and a discussion can be started.

[delfastTions]

@darkv0rt3x i had the same thought yesterday, while i was writing yesterday's post. you're right, there will be a little 'confusion' at some point and you'd have to go back quite a few pages to see all the slides (i think there will be 16 in total).
my thought is that i might open an extra thread for this topic so that all the information can be collected there and a discussion can be started.

Opening a new topic with all these slides would be the right and convenient solution.  If you make such a topic, then I think the community will approve it.  


Lately, I have been concerned and interested in one slightly theoretical question related to LN.  As the number of LN users grows, the number of channels will obviously grow.  Accordingly, if the growth in the number of users and channels is very fast, then the mempool will be filled with a flow of transactions for opening / closing channels, commissions will increase, and this is important for users of channels and micropayments.  As a result, at some threshold values, we can get a complete collapse of the entire system.  So this is a theoretical question, did anyone even calculate the maximum possible growth rate of LN in such a way that the mainnet would work no less normally, without huge commissions, and so that the massive introduction of such innovations would not completely disrupt the functioning of Bitcoin itself.  

If someone roughly knows the answer, then write what you think about it.
Or, if you know, post a link where our fellow forum members discuss such issues here in BTT.

[d5000]

So this is a theoretical question, did anyone even calculate the maximum possible growth rate of LN in such a way that the mainnet would work no less normally, without huge commissions [...]

Paul Sztorc (who thinks that Lightning alone can't solve the scaling problem, what is disputed by others) has calculated that in the very best case, we could onboard 23,251 users per block, or about 2-3 million users per day. But that's of course not a realistic scenario: this would only be possible if 1) all block space was occupied by LN funding transactions and 2) if in each block, one single input spends to all channels in an enormous (non-standard) transaction.

It's more realistic to calculate a "maximum" value of around 3.000-5.000 channel openings per block, as a rule of thumb (that would be Taproot multisig transactions, with 250 to 300 vbytes each, which according to Sztorc can save over 100 vbytes when closing them compared to P2(W)SH).

But we further have to reduce this amount if we want a scenario like what you mention: that the "normal functioning" of the network is not affected and fees stay low.

The really heavy transactions in LN are the closing transactions, which can contain RSMCs ("commitment transactions", these include the penalty if your channel partner tries to cheat) and/or HTLCs (those in the case you only route a transaction from another sender to a receiver). You can see at this page the expected weights of each Lightning-style commitment/HTLC transaction and output type. There are a lot of options, so the transaction can have different weights, but expect them in all cases to be larger than 500 vbytes, often larger than 1000.

Thus the number depends also on how many times channels would need to be closed. Channels could be open for years, or even infinitely, so we probably need much less closures than openings. I think it would be a good idea to "reserve" 20% of block space for channel closures. Let's reserve 50% additional space for other on-chain activity, so 30% would be left for LN onboarding.

My very rough estimation would be then that we can onboard LN users for about a third of the maximum number, or about 1500 per block. This is very optimistic but could be realistic once on-chain activity gets lower if LN is used for the majority of small to average payments.

1500 per block means 144 * 1500 = 216000 new channels a day, and thus around 78 million channels per year. Some users will have more than one channel, so I think a realistic absolute maximum for your scenario would be 150-200 million new users per year. Which is quite a lot, because e.g. from families not everybody needs a full Lightning node, and friends which trust themselves somewhat could use "LN accounts" (see this concept) and/or channel factories.

(Edit: Made a mistake in my calculation - corrected it now Numbers are now significantly lower, but I still think LN has not really a drastic growth problem)

[cygan]

the lightning dev kit (ldk) has now been updated to version 0.0.115, fixing some bugs - here are some of the most important ones:

• transaction rebroadcasting is now more robust
• the ldk user experience has been improved via lots of small fixes
• bolt12 and anchor outputs are progressing in-sync with the development roadmap

https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.115

[delfastTions]

So this is a theoretical question, did anyone even calculate the maximum possible growth rate of LN in such a way that the mainnet would work no less normally, without huge commissions [...]

Paul Sztorc (who thinks that Lightning alone can't solve the scaling problem, what is disputed by others) has calculated that in the very best case, we could onboard 23,251 users per block, or about 2-3 million users per day. But that's of course not a realistic scenario: this would only be possible if 1) all block space was occupied by LN funding transactions and 2) if in each block, one single input spends to all channels in an enormous (non-standard) transaction.

It's more realistic to calculate a "maximum" value of around 3.000-5.000 channel openings per block, as a rule of thumb (that would be Taproot multisig transactions, with 250 to 300 vbytes each, which according to Sztorc can save over 100 vbytes when closing them compared to P2(W)SH).

But we further have to reduce this amount if we want a scenario like what you mention: that the "normal functioning" of the network is not affected and fees stay low.

The really heavy transactions in LN are the closing transactions, which can contain RSMCs ("commitment transactions", these include the penalty if your channel partner tries to cheat) and/or HTLCs (those in the case you only route a transaction from another sender to a receiver). You can see at this page the expected weights of each Lightning-style commitment/HTLC transaction and output type. There are a lot of options, so the transaction can have different weights, but expect them in all cases to be larger than 500 vbytes, often larger than 1000.

Thus the number depends also on how many times channels would need to be closed. Channels could be open for years, or even infinitely, so we probably need much less closures than openings. I think it would be a good idea to "reserve" 20% of block space for channel closures. Let's reserve 50% additional space for other on-chain activity, so 30% would be left for LN onboarding.

My very rough estimation would be then that we can onboard LN users for about a third of the maximum number, or about 1500 per block. This is very optimistic but could be realistic once on-chain activity gets lower if LN is used for the majority of small to average payments.

1500 per block means 144 * 1500 = 216000 new channels a day, and thus around 78 million channels per year. Some users will have more than one channel, so I think a realistic absolute maximum for your scenario would be 150-200 million new users per year. Which is quite a lot, because e.g. from families not everybody needs a full Lightning node, and friends which trust themselves somewhat could use "LN accounts" (see this concept) and/or channel factories.

(Edit: Made a mistake in my calculation - corrected it now Numbers are now significantly lower, but I still think LN has not really a drastic growth problem)

Judging by your answer and by those numbers of possible channels that provide transaction flows throughout the global financial system, the possibilities of bitcoin plus LN are still not enough. 
Even theoretically.  Therefore, further development of the system is probably only possible by creating settings already above the LN channels themselves.  I still hardly understand how this is generally possible, given the accuracy and error-free execution of all transactions. 
Is this even theoretically possible, or will bitcoin just keep the function of "digital gold" and no one will attach add-ons to it?  But it is not at all clear how this can be limited or prohibited. 

In general, here we need to wait for some kind of cardinal decision, most likely according to the already proven approval scheme by miners, approximately how Taproot was introduced with signal inserts into blocks.

[darkv0rt3x]

One other question.

A couple of weeks ago I tried to play a little with htlcmax and htlcmin of my Core Lightning node because I was told that setting lower htlcmax could help nodes keeping more balance over more time in one of the sides of the cahnnel and avoid to rebalance so often. So, I changed some of these values but now I wanted to set them back to the defaults!
Anyone knows what value to set to htlcmax to make it "default"? Would it be the total capacity of the channel or maybe only the outgoing capacity?

The default value of htlcmax in the Lightning Network protocol is the total capacity of the channel. This means that the maximum amount of an HTLC (Hash Time-Locked Contract) that can be sent through the channel is equal to the total capacity of the channel.

To set the htlcmax value back to the default, you can set it to the total capacity of the channel. You can find the total capacity of the channel by checking the channel information on your Lightning node. In the case of LND, you can use the lncli channelbalance command to get the total capacity of all your open channels.

Once you have the total capacity of the channel, you can set the htlcmax value to that amount. You can use the lncli updatechanpolicy command to update the channel policy, where you can set the htlcmax value for your outgoing and incoming channels.

For example, if you have a channel with a total capacity of 0.01 BTC, you can set the htlcmax value to 0.01 BTC by using the following command:

The following code I will write for Arduino.
lncli updatechanpolicy <channel_point> --max-htlc-milli-satoshis=10000000

Here, <channel_point> is the channel point of the channel you want to update. The --max-htlc-milli-satoshis flag sets the maximum amount of an HTLC in milli-satoshis, where 1 satoshi is equal to 1000 milli-satoshis. So, in this example, the --max-htlc-milli-satoshis flag is set to 10000000, which is equivalent to 0.01 BTC.

Thank you for the thourough explanation. I'm using Core Lightning though, but I can manage to set the values to both parameters with Core Lightning.
But wouldn't it be more reasonable that htlc_max be lower than the local / remote balance instead of total balance?

[Wind_FURY]

This might be good for non-technical people who want to try actually using Lightning, https://lightning.engineering/posts/2023-04-26-litd-release/

It's also probably good for fee generation with their "One Node for Many Users" feature.

There's also this very practical feature.

With zero confirmation functionality, Pool users can now purchase or sell Lightning Network channels without the need for on-chain confirmations. A Lightning business, or Lightning service provider (LSP), can purchase inbound and outbound zero-conf channels for a user to give them the ability to send payments over the Lightning Network in a fully non-custodial manner, without requiring the end user to understand Lightning liquidity.

[darkv0rt3x]

This might be good for non-technical people who want to try actually using Lightning, https://lightning.engineering/posts/2023-04-26-litd-release/

It's also probably good for fee generation with their "One Node for Many Users" feature.

There's also this very practical feature.

With zero confirmation functionality, Pool users can now purchase or sell Lightning Network channels without the need for on-chain confirmations. A Lightning business, or Lightning service provider (LSP), can purchase inbound and outbound zero-conf channels for a user to give them the ability to send payments over the Lightning Network in a fully non-custodial manner, without requiring the end user to understand Lightning liquidity.

This is only for LND users or Core Lightning users can also try it?

[darkv0rt3x]

Have anyone came across this site with development of some projects around Bitcoin and LN?
https://geyser.fund/
I found it on Reddit and decided to link it here! Maybe it is of interest of others that doesn't use Reddit!

[Timelord2067]

Hello again, my last two lightning channels on my Zap app won't close - even recently when the mempool was empty and I used the high fees setting. (Neither balance has shifted in a very long time)

One is with BC games, the other is coinplaza - I was just wondering is there anything I can do to force their closure outside of making contact with either site and asking them to close the channel at their end?


I'd like to revisit Lightning Network as I believe it is essential for micro payments, however a great many nodes are now hidden behind the onion curtain, so I'll either have to find an app that has an in built Tor connection setting, or find channels in the clear that will connect with small (sub $100) channels.

1ml.com website shows a great many nodes that are in the clear, but when I try to connect, the channels are closed immediately so I'm wasting my time at the moment establishing new channels hence I've been closing all I have.

[darkv0rt3x]

Hello again, my last two lightning channels on my Zap app won't close - even recently when the mempool was empty and I used the high fees setting. (Neither balance has shifted in a very long time)

One is with BC games, the other is coinplaza - I was just wondering is there anything I can do to force their closure outside of making contact with either site and asking them to close the channel at their end?


I'd like to revisit Lightning Network as I believe it is essential for micro payments, however a great many nodes are now hidden behind the onion curtain, so I'll either have to find an app that has an in built Tor connection setting, or find channels in the clear that will connect with small (sub $100) channels.

1ml.com website shows a great many nodes that are in the clear, but when I try to connect, the channels are closed immediately so I'm wasting my time at the moment establishing new channels hence I've been closing all I have.

You also ave amboss.space which is a growing Lightning Network hub of nodes, channels, services, etc. Another option is also to find loops in https://lightningnetwork.plus. Many people here are seeking partners to open channels of every range of values.

About your channels, you should probably try to check the closing TxID, if you already have one and check it with a block explorer!

[Wind_FURY]

Based on the latest development, "what's currently the easiest way to install a Lightning Node", and other questions about Lightning will probably be one of the most asked questions in Bitcoin Stack Exchange. The "Ordinals thing" may have started a incentivization flywheel which will be spreading across the network.

Plus isn't Blockstream's Liquid Network built for something like the "Ordinals thing"?

This might be good for non-technical people who want to try actually using Lightning, https://lightning.engineering/posts/2023-04-26-litd-release/

It's also probably good for fee generation with their "One Node for Many Users" feature.

There's also this very practical feature.

With zero confirmation functionality, Pool users can now purchase or sell Lightning Network channels without the need for on-chain confirmations. A Lightning business, or Lightning service provider (LSP), can purchase inbound and outbound zero-conf channels for a user to give them the ability to send payments over the Lightning Network in a fully non-custodial manner, without requiring the end user to understand Lightning liquidity.

This is only for LND users or Core Lightning users can also try it?

I think just for LND. The technical documentation mentions only LND in "get started", https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/get-lit

[Timelord2067]

About your channels, you should probably try to check the closing TxID, if you already have one and check it with a block explorer!

Zap doesn't provide that information otherwise I would have used the accelerator services (free ones) to accelerate the TX.

Each time I close Zap and restart it, the two channels revert to open, not closing so it doesn't appear as though a true closure has occurred.

Thanks for the channel links suggestion, I'll check them out.

[Kryptowerk]

BlueWallet is discontinuing its service, so I was wondering which of the mentioned LN wallets in OP would be the best to move funds to:
- https://phoenix.acinq.co/
- https://breez.technology/
- https://blixtwallet.github.io/

Gladly listening to thoughts about any of the three mentioned wallets from some of the lightning OGs here.
Thanks in advance.

[darkv0rt3x]

BlueWallet is discontinuing its service, so I was wondering which of the mentioned LN wallets in OP would be the best to move funds to:
- https://phoenix.acinq.co/
- https://breez.technology/
- https://blixtwallet.github.io/

Gladly listening to thoughts about any of the three mentioned wallets from some of the lightning OGs here.
Thanks in advance.

BlueWallet is discontinuing which service?

[Kryptowerk]

BlueWallet is discontinuing its service, so I was wondering which of the mentioned LN wallets in OP would be the best to move funds to:
- https://phoenix.acinq.co/
- https://breez.technology/
- https://blixtwallet.github.io/

Gladly listening to thoughts about any of the three mentioned wallets from some of the lightning OGs here.
Thanks in advance.

BlueWallet is discontinuing which service?

They are discontinuing their Lightning node (Lndhub.io)
Read their statement here: https://bluewallet.io/sunsetting-lndhub/

Even they recommend to use either phoenix or breez wallet.

[n0nce]

BlueWallet is discontinuing its service, so I was wondering which of the mentioned LN wallets in OP would be the best to move funds to:
- https://phoenix.acinq.co/
- https://breez.technology/

I only know and tried these two. Working very well. What I like about Breez is that it does have 'developer commands', so it gives me the peace of mind that in a worst-case scenario, I could use regular old LND commands to (force) close any open channels and send myself the resulting on-chain funds.

Just to be clear, I have never actually needed it on any of these wallets, but it's still nice to have.

BlueWallet is discontinuing which service?

They offered a hosted / online Lightning wallet in their Bitcoin wallet app.

[Kryptowerk]

BlueWallet is discontinuing its service, so I was wondering which of the mentioned LN wallets in OP would be the best to move funds to:
- https://phoenix.acinq.co/
- https://breez.technology/

I only know and tried these two. Working very well. What I like about Breez is that it does have 'developer commands', so it gives me the peace of mind that in a worst-case scenario, I could use regular old LND commands to (force) close any open channels and send myself the resulting on-chain funds.

Just to be clear, I have never actually needed it on any of these wallets, but it's still nice to have.

BlueWallet is discontinuing which service?

They offered a hosted / online Lightning wallet in their Bitcoin wallet app.

Thanks for the input. Command line options (breez) sound good as a nice last resort. I just installed and don't get any connection, so it's neither allowing me to generate a lightning invoice, nor an on-chain address.
Especiall the latter seems very weird to me - the error notification says "Not able to obtain Bitcoin address from Breez-Server. Please check your Internet-connection". - Are they storing the keys online, or why would you need a connection to show an onchain public address?

Trying out blixt now. Seems to be still WIP but seems to be the only open-source option.
UPDATE: Installed Phoenix now, since blixt doesn't have offline-watchtower (yet).
When I try to send from bluewallet to Phoenix I get an error (independant from the amount I try to send) "API error: Payment failed. Does the receiver have enough inbound capacity? (code 10)"
UPDATE 2: After restarting Phoenix and bluewallet a few times and trying several different payment sizes, it finally worked.

Oh and on another note: I am not familiar with Lightning too much, how would developer commands protect you in a worst-case scenario?