Topic: The Lightning Network FAQ - page 5. (Read 32058 times)

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"?


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

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!

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.

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!

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

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.

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?

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.

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

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)

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.

@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.

@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

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

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.

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.

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/

Simple, because if you have on-chain coins, then you can make a single on-chain transaction alone, so there is no coordination needed with another party or anything like that. It is like on those pictures: "Money then could be LESS LIQUID in the Lightning Network than it is on-chain". So, the conclusion is simple: in on-chain payments that problem simply doesn't exist.

If you want to find something similar on-chain, then you can check CoinJoin or cut-through, or any kind of batching. And those things were proposed before, even some of them are actively used, like CoinJoin in JoinMarket, or batching in many services like mixers, exchanges or casinos. When it comes to batching and cut-through, it is not decentralized and non-interactive yet (because we still cannot join transactions in P2P way, like for example MimbleWimble can do), but maybe after next soft-forks we will get there.

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.

as i have already written and indicated, further slides on this complex subject will follow.
these will then hopefully make the splicing topic even more understandable for us.