What questions do you have about Lightning?

[GBKS]

Please post each question in a dedicated comment. Then we can use replies to each comment to discuss and answer.

Goal is to gather all the questions we have to inform what we should discuss in calls and in the guide.

[GBKS]

How does Muun manage to have a unified balance? What happens if I receive on Lightning and want to send on-chain, or vice versa?

[GBKS]

Based on this comment, your Muun funds are always on-chain (as of Jan 20, 2021, with plans to change this). Submarine swaps are used for Lightning transfers, presumably with Muun servers being the swap providers. That means that on-chain fees are required here and there.

[Bosch-0]

Just my 2c but the unification is only present in UI, technically on-chain and Lightning are separate. I like Phoenix's solution more so than Muun's for this.

[GBKS]

Will Lightning solve scaling to allow everyone on earth to use Bitcoin? Will we need a "Layer 3" or can we solve the remaining scaling limits via application layers?

[moneyball]

The block size is the limiting factor. In order to scale to everyone one of the following need to occur:

1. Figure out ways to share UTXOs while maintaining most important properties of bitcoin
2. Some future innovation or invention
3. Increase block size 10-100x (over like a 20-30 year period)

That said, LN helps bitcoin scale substantially (perhaps 1-2 orders of magnitude) and the innovation pipeline will help even more (taproot will make LN channel closes more efficient creating more block space, channel factories might enable certain applications of LN scale, etc.).

So, for bitcoin-as-a-currency use case, if on-chain bitcoin scales to ~1M people, and LN scales to 10-100M people that is a pretty exciting scaling roadmap for the next 5-10 years while we try to figure out how to scale to 8B (plus a lot of machines).

We should also keep in mind custodial solutions will exist and semi-custodial solutions will exist, which can require trust among a small or large set of people, ranging from a household, to a neighborhood or village, to a city or region, to a nation.

[Bosch-0]

Something to add is that onboarding directly to LN non-custodially, currently anyways, still requires at least one on-chain tx to create a channel for that user resulting in the same scaling issues. For LN to be truly scalable things like channel factories (where new channels can be made without an on-chain tx) will be necessary.

[sbddesign]

What will the lightning node ecosystem look like under mass adoption?

• Will nodes be run primarily by individuals and families?
• A mix of individuals and companies?
• Or will nodes be run by primarily companies?
  • If so, is there a centralization risk from a few dominant players emerging?
  • Or are there economic incentives in bitcoin and lightning that will help to prevent centralization and serve people best?

That may be beyond the scope of what we would ever talk about in the Guide, but it is something I am curious about.

[pavlenex]

I think this is something everyone who's tapped a bit into LN is curious about and something that we have to consider when designing non-custodial products.

[pavlenex]

@moneyball I remember you at some point sharing a medium post that compares LN to VISA, banking, etc. I tried to dig it up no luck, if you still remember the article, I know it answered some of these questions in an interesting way.

[moneyball]

https://github.com/lnbook/lnbook/blob/develop/01_introduction.asciidoc#scaling-blockchains

[moneyball]

@sbddesign I assume by nodes you mean on-chain full nodes? Because LN nodes need to be run by each user if they want to be non-custodial, at least, a "leaf" LN node (doesn't have to have routing functionality).

For on-chain full nodes, I imagine a future in which all kinds of folks will use them:

1. Institutions (corporations, Wall Street, nations, etc.)
2. Miners, of course
3. Crypto financial institutions (exchanges, financial services, etc.)
4. Large merchants
5. Small merchants
6. Small communities (villages, neighborhoods)
7. Households, families

There is no question categories 1-4 will be 100% penetration since enough volume and money will be at stake, and they'll have the resources and wherewithal to do it. This would be tens of thousands of entities.

Categories 5, 6, 7 are unlikely to ever achieve 100% penetration, but I think material % penetration in each category is realistic. Imagine today's Raspberry Pi nodes sold to hobbyists turn into something integrated into existing home/business devices (routers, set top boxes, thermostats ... whatever the future's home/office devices look like), by only adding $5-10 to the BOM, and voila, the user has a "bank in a box." It'll be no different than buying a home device today and using it. That device can then be used by all of the laptops, phones, and other devices members of a household use and can support multiple wallets.

[Bosch-0]

Will nodes be run primarily by individuals and families?

Steve covered on-chain nodes very well above but regarding LN nodes here is some things to consider.

LN nodes will be primarily run on people's mobile devices behind the scenes. If the LN ends up getting a few order of magnitudes larger the network graph will be more challenging to store and use on a mobile device resulting in a routing-path-determination trade-offs (most likely using something like trampoline nodes at this stage).

What's a trampoline node? It is a node you are essentially trusting to have a accurate copy of the network graph and construct a payment route for you. It has similar trade-offs to SPV nodes. Users could connect to multiple trampoline nodes so they aren't trust one entity.

Or will nodes be run by primarily companies?

It is likely non-custodial lightning service providers (LSPs) will be the primary avenue people are on boarded through. Breeze, Muun and Phoenix as essentially version 0.1 LSPs. This is a centralization concern as they could easily be forced to require KYC/AML and/or potentially censor users, as well as be shutdown.

These two blog posts dive a bit deeper on this potential centralization issue with LSPs.

https://medium.com/breez-technology/sources-of-centralization-on-lightning-and-why-they-matter-b7aa3352231f
https://medium.com/breez-technology/envisioning-lsps-in-the-lightning-economy-832b45871992

[danielnordh]

If I have funds onchain, and a Lightning wallet (say Blue wallet), how can I fund the Lightning wallet?

[GBKS]

One option is via a submarine swap, in which you send the on-chain funds to a swap provider, and they send the Lightning funds to your Lightning wallet. There's basically an intermediary who has funds both on L1 and L2 and "exchanges" on-chain to Lighting for you.

The second option would be to use the on-chain funds to create a new Lightning channel. Then you can send the funds via that channel to your wallet. This requires having access to a node and being able to open channels that can connect to your Lightning wallet.

[Bosch-0]

You always need an on-chain component with hot keys to use LN though you can abstract that interaction away with submarine swaps like Christoph said (I'd suggest checking out phoenix for a demo of this).

Another way you can interact between on-chain and Lightning with LND is funding a channel with a PSBT from say a ColdCard. Your LN channel will still have it's own on-chain wallet but you can by-pass this with PSBT. I 'think' you can close a channel and have the on-chain funds go to the Coldcard rather than the hot on-chain wallet but I don't think it's super user friendly atm.

[psacramento-gh]

What is done to ensure that enough funds are inside of channels, so that it is still possible to pay on-chain fees, even in the case of a sudden channel closure?

[moneyball]

I'm not sure how HTLCs are related to this? They're used to conduct an (off-chain) LN payment. On-chain fees would only be paid when closing a LN channel. The fees paid cannot exceed the channel capacity so any channel closing transaction that would be broadcast would simply get stuck in the mempool if the fees are too low to get mined in a block.

[Bosch-0]

Yep moneyball is correct. You will have to wait until fees become lower so you can close the channel or you could send some sats to that channel so it has enough funds to close it.

Like moneyball said all it is doing is essentially sending a transaction from a 2of2 multisig wallet (which is what a channel is) back to your regular on-chain wallet.

[psacramento-gh]

I thought the HTLCs were responsible to perform the 'elevation' of the funds from on-chain to the second layer (channel established between two parties) according to a set of rules, such as expiration time...

[moneyball]

HTLCs are used for payments. They ensure a payment can be made through a path of nodes, atomically, so that the payment either fully succeeds or fails. They do modify the commitment transaction when in flight, as shown here https://github.com/lnbook/lnbook/blob/develop/09_channel_operation.asciidoc#bob-settles-the-htlc-with-alice

I'd recommend reading this section to learn how a payment channel is created https://github.com/lnbook/lnbook/blob/develop/03_how_ln_works.asciidoc#multisignature-address

[psacramento-gh]

I will do it! Thank you very much, @moneyball and @Bosch-0 .

[Bosch-0]

What are ways in which a Lightning network payment can fail and what happens when they fail?

[johnsBeharry]

most of the errors im aware of are routing based errors. here's a list of some of them.

• https://wiki.ion.radar.tech/tutorials/troubleshooting/error-codes

Edit:

• ErrNoPathFound
• ErrNoRouteFound
• ErrInsufficientCapacity
• ErrMaxPendingChannels
• ErrSynchronizingChain
• ErrChanTooLarge

I believe what is excluded from that page are are possible new Multi Part Payment errors since it may be technically possible for a partial settlement to happen. Would need to verify this though.

[Bosch-0]

What are the different ways in which a channel can be closed and what are the caveats of each channel close type?