pull down to refresh

I've been pondering how LSPs (lightning service providers) might pan out over time and how that might affect fees, and I am wondering what everyone else is thinking. Some people will always prefer to manage their own channels, and for some specific use cases, that might be preferable. But I am thinking about the broad userbase that does not want to do that. We will need a massive LSP infrastructure to onboard people and to enable insane amounts of payments.
LSPs will need to efficiently open and adjust channels for users, using their own liquidity or sourcing liquidity from other providers, using just-in-time channels, batching and/or splicing to reduce costs and wait times. Across all this, along with facilitating payments, they need to make their business model work and offer different options for users to pay for their services.
Users might be able to:
  1. Pay-as-you-go (pay X for Y more liquidity for Z amount of time)
  2. Pay X per month for Y inbound liquidity
  3. Pay X per month for unlimited liquidity
  4. Nothing for liquidity, but higher transaction fees
A wallet might also automatically choose an appropriate LSP based on what is the best and most appropriate deal at the time.
Let's look at user scenarios:
  • If someone sends and receives the same amount every month, they will never need more liquidity. They just draw down the same channel and fill it up again. So they would only pay the LSP for them assigning that fixed amount of liquidity to them. Maybe options 1 and 2 are good for them.
  • If someone receives more than they send (they save a certain amount every month), they will need more and more inbound liquidity over time. They might choose option 2.
  • An online store that receives a ton and can't really estimate how much, might go for option 3.
  • For option 4, it depends if the higher transaction fees are fixed or percentage-based.
It's a bit like choosing a data plan for your phone (or for internet at home). You can get a prepaid card, a regular plan with certain limits, or go unlimited. And there are separate plans for small and large businesses, etc. And there are massive amounts of complex infrastructure behind these service providers to make it all work.
So when someone starts using a lightning wallet, maybe they have to first pick an LSP and a plan before being able to receive. Or maybe they get a first channel for free and pay higher fees, and are then prompted to choose a plan. Maybe they need to wait an hour until the LSP has enough channel opens for a batch/splice, to reduce costs. A complex market at work.
Is that how things might pan out? Am I completely off? Is it worth mocking up different scenarios?
#bitcoin #LN #BTC #Lightning #LSP #service #zaps #sats #wallet
LSP
  • liquidity service provider = when you offer channels liquidity
  • lightning service provider = when you offer wallet, infrastructure, nodes etc
I think we should make a clear difference between these two, are not the same thing.
reply
Great detail, so is a liquidity provider just sending liquidity to an existing chanel ad charging for it, meawhile the lightning provider is providig both, liquidity ad channels openig?
reply
yes indeed. Example:
  • megalithic is just a liquidity provider
  • Zeus is a liquidity (through Olympus LSP) and lightning provider through embedded node
  • Green / Phoenix is a liquidity (Greenlight / ACINQ) and lightning provider (embedded LN node)
  • Blixt is just a lightning provider (you open channels with whoever you want, even that they also have a small LSP liquidity node for quick onboarding)
reply
I hope we never expose users to the idea of options for LSPs and plans in the onboarding flow (maybe somewhere in the settings in an advanced panel or something) - onboarding has to look like "write down your seedword -> here's your invoice, you're ready to go!", anything more and we've lost the vast majority of users already (and even just writing your seedword loses lots of folks).
Most likely, wallets will simply partner with an LSP (or a few) and split some of the fees with the LSP. Users can pick a different wallet if they don't like the fee structure.
reply
0 sats \ 1 reply \ @gbks fwd 8h
Sure thing. It's great if the default works well to onboard people. And maybe once they have a sense for what their needs are, they can go in and fine tune things.
What I am curious about is whether the actual economics and marketplace dynamics will pan out that way. Those might in the end dictate what options users have. Can we already know at this point in time how things will go? Not sure even the teams that run today's LSPs do, considering the tech is still maturing and adoption and usage patterns will likely change.
reply
Wallets are in charge of their onboarding UI not LSPs
reply
It's a bit like choosing a data plan for your phone (or for internet at home)
yep, something like that. LSP will be the big business in the future, but we need it standardized for all wallets https://github.com/BitcoinAndLightningLayerSpecs/lsp
reply
This is exactly what I was thinking about, some sort of API that gather data from all available LSPs and provide network data to wallets and other lightning clients, to select the most suitable deal.
reply
Yeah I would like to see in all these mobile node wallets options to choose a bunch of LSP from a drop down list (vouched by devs or community) and the new user will have a smooth experience starting with these mobile wallets.
Then each one could show off their offers and user can choose the one that is more suitable for its use.
I always see in their support chats, newbies asking "with who I can open a channel?" Is quite hard decision as a noob.
reply
a mockup from the Bitcoin Design community
reply
10 sats \ 0 replies \ @bluematt 13h
IMO If we ever expose a UI with that much detail to the user we've lost. That's wayyyyy too complicated for the vast majority of folks when they're just getting started (sure, in an advanced panel in settings, no problem).
The entire concept of a "channel" (let alone the duration of it or the size of it) should never be exposed to 99% of lightning users, and IMO the quicker people accept that the quicker LN will actually see some real users.
reply
super cool!
reply
I like this user-powered scenario, I was visualizing a more data-driven approach that this APIs can provide. A merge of both could be really helpful for newbies, usually less decisions they need to take, more chances they will be onboarded successfully!
"with who I can open a channel?" Is quite hard decision as a noob.
probably because:
  • they don't know LSPs are a thing
  • have no visibility of the network and most valuable ways to open channels
reply