I 100% agree with you. I think no one can specialize in all the things. Lightning has a very big surface area and there's a lot of different things you can do with it. Early folks had to build the full stack like you said, but I think we'll definitely see less of that. Especially as you think about how difficult it is to run an LSP from a capital standpoint. Not everyone is going to have the large amount of upfront capital that you need to start an LSP for their wallets. You'd have to have millions of dollars just to launch to your users.

As soon as we see LSPSpec adoption, I strongly expect the wallet app / liquidity provider roles to separate. We at Synonym do not offer liquidity services to US users due to legal constraints. It is our intended purpose to work towards a world where a wallet and LSP can be a separate entity so a third party LSP can provide liquidity to Bitkits US users.

I don't think liquidity is necessarily always going to be an interesting and complex problem for two reasons. First, the network will gradually become less dynamic as people who transact frequently will establish long-lived and maximally direct connections with one another. Second, tools, algorithms, and data will be available to help non-experts deploy liquidity in an increasingly effective way.

Even with the LSPSpec, there are still mechanisms needed to help users select the right LSP because they differ in their feature set, reliability, and more. I can see a future where LN Explorers aggregate price/feature/reliability data and suggest LSPs to connect to. Some smart entrepreneur will come up with a business model for that I am sure.

I think they will definitely still exist and be very helpful. Ideally they'd adopt the spec as well.

I would like to see them support the LSP spec

I think in 2024 we'll see more of large new players in providing liquidity. There's definitely interest from folks about this. I think the challenging part is the demand side. If we had $20 million dollars of liquidity pop into Magma (or other service) tomorrow would it get used up? It'd take a while to actually get that deployed out. To counter argue myself, I think demand will increase as well in the coming year+.

We first need to increase the demand for LN payments before any huge capital will flow in. Capital follows demand. The best way to do that is to keep improving the LN experience and keep onboarding users.

We already have Bitfinex, Kraken, and other big companies with LN nodes. They are there and ready to supply when needed.

Predicting timelines is always a guessing game. But I'm actually of the opinion that in the near term, liquidity on the network is not a bottleneck for Lightning. We can still scale to way more payment throughput and success rate with exactly the same amount of liquidity we have right now.

Liquidity is a good that will be present as soon as sufficient demand is visible. When people want to use Lightning, the liquidity will be there. When large exchanges adopt Lightning or new merchants come onboard, they will bring the liquidity they need themselves, or attract it by exerting demand.

I'm not convinced that Lightning will be a great place for "yield" in the near future either. It may be a good place for "risk-free rates", but not for earning substantial yield, compared to shitcoin schemes, bonds, or the stock market.

Yield is fiat, Lightning fees are just ROI. I think we'll see whales entering the space in 24'.

Taxes are a big headache especially for merchants trying to adopt Bitcoin. It's one thing to install an app to charge customers. It's another thing to register the earned Bitcoin in your cash register and later in your accounting program.

Would a bill like the first 2.25M sats ($600)spent via BTC see merchant adoption explode?

Not sure I understand but relieving merchants of bitcoin accounting would definitely help.

I don't think laws are the reason people are not transacting with Bitcoin more. It's hard money that's expected (by those who hold it) to appreciate in the future.

Merchant adoption will come when Merchants actually demand Bitcoin, either by giving discounts for those paying in bitcoin, or not accepting fiat. Bitcoin and Lightning UX is only a part of this. The greater factor (IMO) is Gresham's Law and the use cases that only bitcoin can serve and fiat cannot.

I don't know of any plans for that, but I think it'd be nice as well but technically pretty challenging. They'd all at least have to be using the same implementation. Going from like a Greenlight to LND would be very challenging if its even possible. So there's have to be some sort of standard there.

That involves you exporting your exact channel states (commitment transactions) and taking downtime to switch providers.

I think it will always be easier to just move your funds and setup anew with some other provider. You can use BIP32 to maybe reuse the same seed, but actually moving channels and keys doesn't make much sense to me.

Yeah, we've seen a fairly large increase in builders using LDK from Spiral. I think there will continue to be more of this in the coming years.

focused use cases over the last year?

A ton. New apps like Mutiny, Fedi, and more are all mobile-first, and are going to add novel ways to use Lightning, which I think will bring new people in.

For me, LSP mainly means network connectivity services. If an ISP connects you to the Internet, an LSP connects you to Lightning. You can provide internet services not as an ISP, or Lightning services not as an LSP. The main service an LSP provides is liquidity services via opening channels.

Sure! So at @voltage_cloud, we're an infrastructure provider for Bitcoin. That means we provide everything you need to build & use Bitcoin and the Lightning Network. We provide infrastructure (node hosting & management), connectivity (Liquidity Service Providing), analytics (metrics, accounting, insights), and backend services (Esplora, RGS, etc). We help companies incorporate both Bitcoin Layer 1 and Lightning Layer 2 into their products and services. We help folks go from testing and idea to scaling in production very easily.

River offers a Lightning API that allows developers to easily integrate with the Lightning Network via a simple HTTP API. We support sending and receiving to and from BOLT11 invoices, LNURLs, and onchain addresses, all without having to worry about channels, liquidity management, peer selection, or infrastructure.

River is a direct Lightning Service provider as opposed to a Liquidity Service provider (eg. Magma, Surge, etc.)

LSP is a Lightning Service Provider. Our current focus lies on providing techniques and the liquidity to create a great wallet/node experience. You can get a channel from our widget for example.

On the other hand, Synonym is developing the Bitkit wallet and focuses on innovative peer2peer tech (Slashtags) to further decentralize the web. We focus heavily on open source software.

On public channels, routing fees and max/min htlc sizes can be used to steer payments in one or the other direction. This is very helpful.

Private channels on the other hand don't need that and can just have a static fee, maybe based on usage patterns.

I don't think I have a direct answer to this question. It all depends on a lot of factors. Generally speaking with our customers we have no fees or incredibly low fees on private channels because these are generally end users of a noncustodial mobile wallet.

I don't think anyone has created a direct comparison you're asking for in #1. If you are asking about liquidity services only it's a little easier to compare side by side. However if you are talking about company's products overall it's more challenging to compare all providers side by side regarding fees and such

The only LSP fee rate website I can think of is Amboss Magma and the LnRouter LiqAds marketplace. I don't think there is a website with all the rates.

You can purchase a Blocktank LSP channel from our website on https://blocktank.to/#widget.

Let's do it!

The obvious benefit to the spec is easier integrations for wallet or system builders into LSPs. Of course it will be positive when it becomes completely integrated across the ecosystem. Second-order effects could likely be more participation from new players in providing liquidity. More LSPs, more liquidity, etc.

I view LSPs as infrastructure for the Lightning Network. I'm not convinced LSPs themselves will attract more people to use LN, but when people are ready, LSPs will make scaling and onboarding way smoother.

LSP > ease of use > non-custodial adoption.

We see that already with Mutiny, Zeus and others implementing LSPs.

• Switch easily between LSPs. Privacy++.
• Creates a competitive market. Better service.
• Everybody can participate.

You might enjoy my recent LSPSpec talk https://www.youtube.com/watch?v=coJzL_2sL9M

Potentially.... We have our own LSP, Flow 2.0, that provides liquidity to mobile nodes. If you are meaning about letting our customer be their own LSPs, yeah it's a possibility and something like Dunder could work there.

It's probably the error messaging from LN itself being very vague. A large part of this is due to the desire to preserve privacy, which is great, but it makes it very hard for us to dig into most of our payment failures and do something about it.

The Lightning report we recently released has some great data and graphs on our failure reasons and rates: https://blog.river.com/the-lightning-network-in-2023/

Well managed routing nodes and sufficient inbound liquidity on the payee node. Paying large nodes in the network has high probability of succeeding, that's not so much the case for smaller nodes which are sometimes less maintained: not enough channels, not enough inbound.
Also, there's more work to be done when in comes to routing algorithms.

At its most barebones, an LSP can just be a regular LN peer that a user has a channel with and relies on for routing & liquidity management.

But yes, logic could be built into/on top of your node to try a payment, and if it fails, retry through a specific LSP. Or, you could have a list of peers you can reliably pay, that you pay directly, and if your destination is not in that list, you use the LSP to access the wider network.

If we're thinking about this strictly from liquidity, More of the second in my view. I don't think it will be winner-take-most, I believe there will be a fairly diverse set.

If we're talking about a more general Lightning provider, I think we'd still see a decent group of offerings that focus in specific areas or types of solutions.

The goal of the LSP Spec is to create an open system and avoid lock-in. Hopefully this plays out. With that said, capital intensive markets tend to be more centralized than non-capital-intensive ones.

One factor that might offset some of this tendency to centralize is that there are diminishing returns to increasingly massive LN channels. A 10BTC LN channel isn't all that useful if the average payment size is 10k sats. Individuals need many channels in order to reach the full network, which means that smaller players can enter the LSP market and sell small to medium sized channels.

The LSPSpec and it's features is on our roadmap. This will improve the Lightning experience enormously. https://github.com/BitcoinAndLightningLayerSpecs/lsp

Not a lot to share, but lots of great stuff. I think 2024 will be a really good year for Lightning. There'll be a bunch of new stuff and preparing for or capturing the next bull cycle.

River is working on a new product to allow clients to hold their own keys and recover their funds without River, all while maintaining a very simple UX and not having to manage liquidity, channels, peers, or infrastructure.

LSPs may technically be a middleman, but the goal of the LSP spec design is to minimize the lock-in a user has with a specific LSP. Lock-In and barriers to entry are what make middlemen bad for a system.

Also, LSPs don't just solve an education problem. They solve a liquidity and capital problem: not every human can own a UTXO, open one or more channels, and manage said channels continually.