Pages:
Author

Topic: The Lightning Network FAQ - page 6. (Read 33222 times)

hero member
Activity: 1260
Merit: 675
I rather die on my feet than to live on my knees
May 09, 2023, 05:16:01 AM
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?
legendary
Activity: 2044
Merit: 1401
Disobey.
May 09, 2023, 02:04:37 AM
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.
legendary
Activity: 3696
Merit: 2219
💲🏎️💨🚓
May 08, 2023, 06:22:00 AM
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.
legendary
Activity: 2898
Merit: 1823
May 08, 2023, 05:59:36 AM
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.

Quote

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

hero member
Activity: 1260
Merit: 675
I rather die on my feet than to live on my knees
May 04, 2023, 06:09:17 PM
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!
legendary
Activity: 3696
Merit: 2219
💲🏎️💨🚓
May 04, 2023, 04:15:38 PM
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.
hero member
Activity: 1260
Merit: 675
I rather die on my feet than to live on my knees
May 04, 2023, 03:44:21 PM
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!
hero member
Activity: 1260
Merit: 675
I rather die on my feet than to live on my knees
May 03, 2023, 06:06:38 PM
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.

Quote

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?
legendary
Activity: 2898
Merit: 1823
May 01, 2023, 11:36:25 AM
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.

Quote

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.

hero member
Activity: 1260
Merit: 675
I rather die on my feet than to live on my knees
April 30, 2023, 03:01:08 PM
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 --max-htlc-milli-satoshis=10000000

Here, 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?
legendary
Activity: 2702
Merit: 1465
April 27, 2023, 01:48:19 AM
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 Wink 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.
legendary
Activity: 3304
Merit: 8633
Crypto Swap Exchange
April 26, 2023, 02:25:37 AM
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
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
April 25, 2023, 09:42:40 PM
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 Wink Numbers are now significantly lower, but I still think LN has not really a drastic growth problem)
legendary
Activity: 2702
Merit: 1465
April 25, 2023, 04:35:18 AM
@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.
legendary
Activity: 3304
Merit: 8633
Crypto Swap Exchange
April 20, 2023, 05:22:24 AM
@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.
hero member
Activity: 1260
Merit: 675
I rather die on my feet than to live on my knees
April 20, 2023, 04:59:58 AM
@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
legendary
Activity: 3304
Merit: 8633
Crypto Swap Exchange
April 19, 2023, 11:31:38 AM
as i promised a few days ago, here are 4 more slides about splicing on the lightning network


hero member
Activity: 1120
Merit: 887
Livecasino.io
April 17, 2023, 09:39:34 PM
What I can not understand, even if I will probably be beaten for this question, is why people not try to propose those new features to bitcoin directly? Yes the lightning protocol was not natively adopted, but to split so much developing power away from bitcoin core can only hurt the project in the long run.
To add to what has been said, integrating the splicing feature or any other new features into bitcoin directly in my opinion would eliminate innovation and experimentation because developers would have to wait for acceptance by the broader Bitcoin community or the Bitcoin Core development team. This in my estimation doesn't foster innovation, competition, and collaboration among different parties and would not allow for greater flexibility, scalability, and efficiency in the overall system.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
April 16, 2023, 07:51:54 AM
What I can not understand, even if I will probably be beaten for this question, is why people not try to propose those new features to bitcoin directly? Yes the lightning protocol was not natively adopted, but to split so much developing power away from bitcoin core can only hurt the project in the long run.

Mainly because Lightning Network isn't part of Bitcoin protocol. As for splicing feature, it's meant to let user use Bitcoin on mainnet/on-chain without close and re-open channel which create 2 on-chain transaction which takes time and could be costly. And FYI, LN can be used for many cryptocurrency and you can even swap between 2 coins on LN through atomic swaps. Bitcoin Core development heavily focus on full node and wallet functionally, so adding feature (such as LN wallet or CoinJoin) would burden Bitcoin Core development and maintenance.
legendary
Activity: 3304
Merit: 8633
Crypto Swap Exchange
April 16, 2023, 05:46:40 AM
here is a interesting list of various projects that have integrated the ldk (lightning dev kit) into their software/code:


https://github.com/peakshift/awesome-ldk/
Pages:
Jump to: