Request inbound channels when you deploy lightning node form the UI

[pavlenex]

One of the biggest UX struggles when it comes to LN is inbound liqudity. Since the majority of BTCPay Server users use the software to receive payments, it would be good if we can try to improve the experience around this.

Usually, the merchant launches the LN node, tests a payment, payment doesn't work, they come to our chat to ask why it doesn't work we tell them they need incoming channels.

While this may not be in the true spirit of independence, I propose that we add a few reputable incoming capacity providers that people can pick from, but also explain to people what's happening and that these are suggestions, they can request it from other trusted sources.

This UI request of inbound channels, may have commercial benefits for the service provider, so it would be good if we can talk 1:1 with them to see how we can get the best deal for our users.

I propose that we do this in the LN deploy wizard, after the first screen.

It is essential that on that page we inform people what is happening, why, and what they need or perhaps don't need to do.

[bolatovumar]

@pavlenex also now that RTL has Loop built-in merchants can use it to get inbound liquidity quite easily. Would be nice if we explained that somehow. I myself didn't know this until not long ago.

Some other ways to acquire inbound liquidity:

https://www.bitrefill.com/buy/lightning-channel/ <-- works really well, I use it myself
https://lnbig.com/ <-- worked for me in the past but I had trouble getting inbound liquidity to my BTCPay instance through them recently. Also fees are much higher now than they used to be
https://lightningconductor.net/channels <-- they open a channel back to you if you open a channel of 0.005 BTC or more to them (worked for me)
https://lightningto.me/ <-- requires that you already have at least 10 public channels with at least 5M sats in them before they will open a channel to you

[pavlenex]

Nice list. Ideally, this needs to be integrated deep into the UI. Users shouldn't thinker, research or have failed payments in order to realize they need incoming liquidity.

I talked to:

• BitRefil
• LNBig
• LightningPlus

All 3 are willing to create an API that we could use. Ideally, the user deploys a node, in the next step of the wizard they are asked to choose one provider (potentially showing price?) and explaining it to them why it's needed, they can skip the step if they don't want incoming and would prefer customers to open channels to them, or if they just want to use node for a different use-case.

also now that RTL has Loop built-in merchants can use it to get inbound liquidity quite easily.

I didn't know this, it assumes LND probably, could be something to document cc @Zaxounette @britttttk

[bolatovumar]

Ideally, this needs to be integrated deep into the UI. Users shouldn't thinker, research or have failed payments in order to realize they need incoming liquidity.

Agreed! Ideally the experience should be as straightforward as possible as getting inbound liquidity tends to be the trickiest part when you are first starting out with Lightning.

All 3 are willing to create an API that we could use.

Nice!

I didn't know this, it assumes LND probably

Yeah, it does. I haven't used it myself but heard from others that it works quite well right from RTL. There is a video showing how it works here: https://youtu.be/_rK4gYaEybE?t=299

[iraszl]

Looping out doesn't work very reliably for me. Maybe it's just me. Also, if you open a large channel to the LOOP node they will move all your balance to their side and then close the channel to move back BTC to their on-chain wallet. Of course they have the right to do this, but it's discouraging for me to spend channel opening fees if the channel won't stay open.

I could be wrong, but maybe looping out may not be desirable for LN to grow liquidity globally. It would be better if new incoming capacity for nodes didn't come from closing down channels, but from node operators opening new channels instead.

So, even if looping out provided a 2-3 step process to generate incoming liquidity for stores, if many do this on the long term it may not be beneficial for the network including the stores.

[xucian]

any progress in this direction?

[dennisreimann]

We are closely monitoring the development of the LSP spec and evaluating options for improving on that front.