LSP Integration

[pavlenex]

We're aiming to do this one in Q1/Q2. It heavily depends on when LDK team ships C# bindings for lighting-liquidity which would allow us to support any LSP specs compliant LSP.

I am starting this issue, so we could begin to discuss the desired UX around LSPs, as this is potentially going to be the hardest concept to agree on, as currently there doesn't seem to be once size fit all approach.

In order to receive a payment, a new node needs to be connected to the network. LSP's help facilitate that, but since the capital is being locked up in channels, obviously they want to charge a fee for this service. This fee currently, can be charged either upfront, or after the payment. Both approaches have different trade-offs which I attempted to illustrate here:

My opinion is that slapping LSP terminology together with channels and all of this aka this style, isn't suitable for our target audience.

On the other hand, abstracting things away could mean that fees for payments would end up being higher, which is arguably even the worse UX especially for our target audience, retail merchants who often deal with low margins and are very fee sensitive.

What I would like to propose is some sort of combination of both approaches, and this is where I'd really like to have some discussions on whether or not it's achievable. To get to the point, our whole idea with the app is that end-user, retail merchant is onboarded by an ambassador which hosts infrastructure required, but is never custodian to merchants funds.

Another consideration we have to add into equation is that we believe most ambassadors would ideally want to charge some sort of fee for the technical IT support they're providing for the merchant, hence we're introducing membership subscriptions.

What I would like to explore is the idea of having LSP01 (the cost-effective option) which is completely abstracted from the merchant, but not the ambassador. Ambassador could ask during the merchant onboarding (which we expect to be in person in most cases) approximate expected revenue, and inalculate that into the membership plan for the merchant, or basically offer subscription plan based on the expected, and later actual revenue.

For example, if you're onboarding someone to your BTCPay Server, and you're charging them certain fee for that, I wonder if you could simply in agreement A) Select default LSP B) pay for channel on behalf of the merchant you're onboarding.

This way technicalities are abstracted from the end user (hooray), the most cost-effective option is selected (hooray), but there are some costs for the ambassadors themselves, especially in scenario of a free trial, where ambassador gives X days to a merchant before they commit to a subscription, the upfront LSP cost is customer acquisition cost in a way for ambassadors.

I believe this is something both @Kukks and @NicolasDorier mentioned in different contexts, so I am logging it in.

For this to be achievable, we'd of course have to fully flash out btcpayserver/btcpayserver#6447 and ensure all the cases are covered there, and hopefully bring LSP integration somehow into the BTCPay Server itself.

I cannot think of many downsides but, I guess this model would heavily be dependable on the Membership Plugin. We could however, design the app in which this can be a happy path, but then user could change LSP's from the dropdown and PAY for the channel upfront, or they click skip in which case they would be opting for JIT or manual channel opening.

[pavlenex]

Kukks:

• Ambassador Node acts as a routing node, and opens a channel to the end-user, while they're connected to the LSP itself; opens zero-conf JIT;

[GBKS]

This is a juicy one. I have a few questions:

• Can LSPs do channel batching to reduce costs per channel? Maybe a user has to wait 10 minutes or an hour or so until enough batch jobs have been registered, but in turn they would pay less. This would not work for urgent situation (customer tries to pay right now), but could be scheduled or based on triggers (liquidity is at 10%).
• I would assume that just-in-time-channels are just going to happen there and there (busy shopping days). If one happens, could another channel open with more liquidity (or a rebalance) automatically trigger to prevent further JIT channel?

Considering someone would pay a membership fee, I'd assume they expect as little hassle as possible. And it's in the interest of the ambassador to keep their expenses down as well (for profit and competitive reasons).

[pavlenex]

• I would assume that just-in-time-channels are just going to happen there and there (busy shopping days). If one happens, could another channel open with more liquidity (or a rebalance) automatically trigger to prevent further JIT channel?

Can LSPs do channel batching to reduce costs per channel?

I think this is up to LSP's and beyond our control. But that's horrible UX imo, our target audience is retail, in person payments, then they may as well just do on-chain payments if they have to wait 10min?

I would assume that just-in-time-channels are just going to happen there and there

Hm not really, imagine your first invoice is 10$, you get JIT for 10$ + some percentage, then you have a payment of 50$, another JIT is needed, then you have a payment of 200$ another JIT is needed. It's really a bad and pricy model.

One more thing @Kukks suggested today is that Ambassadors node is the one opening zero-conf to merchant and is already well connected with LSP's and acts as an intermediary node (potentially making routing fees), which is different to the earlier approach, but it's also a question if ambassadors can afford to lock that much liquidity as well.

[GBKS]

I think this is up to LSP's and beyond our control. But that's horrible UX imo, our target audience is retail, in person payments, then they may as well just do on-chain payments if they have to wait 10min?

This would be more for merchants. A channel could be requested ahead of time before needing it. Maybe you set a maximum wait time. If more people join the batch request, the cost is split.

For retail, a very large LSP might be able to get enough requests to have very short waiting periods. Reminds me a little when you need cash and have to go to a bank that's not yours and get slapped a €5 withdrawal fee.

It's really a bad and pricy model.

Totally, what I was trying to say is to treat it like an emergency if it happens. Maybe there's an unexpected flood of purchases on Cyber Monday or so and the liquidity runs out more quickly than anyone expected. If in that case, a JIT channel has to be done for a payment, the service provided should not let consecutive JITs happen, but instantly fix the bigger problem with a rebalance or a new channel open with extra liquidity. Best to avoid, but have a plan for reducing pain in case it happens.

---

Not sure if my comments are helpful. Generally, it seems like there are a lot of unique scenarios to consider to optimize channel management & liquidity across the network. Intelligent batching seems like a great way to remove some of the pain, but also then requires some infrastructure and users/applications being pro-active.