What is an LSP?

When thinking about the challenge of onboarding, it’s important to remember that many incoming users aren’t coming from bitcoin, they’ll be onboarding directly from fiat. And they’ll need someone to guide them onto the network.

Even experienced, technically sophisticated users could use some help to avoid non-obvious obstacles. For example, even a user willing and able to open her own channels manually will have to spend money first (i.e. move local balances outward to create inbound capacity) before she can receive money, which is the opposite of what most new users would prefer. In choosing a hub for her initial connection, how can she tell which ones are stable and well connected? Even if she uses autopilot to help find active hubs, opening channels with the hubs it recommends is still a bet on the hubs’ stability. She’s betting her set-up fees that she won’t have to repeat the process should one of these hubs decide to close the channel unilaterally.

Those are the kinds of problems LSPs solve. They provide users with a stable connection to the Lightning network, simplified channel management, and liquidity.

While ISP is well known term, you’ve probably never heard about “LSP” before. The similarities between the Lightning Network and the internet in many respects are striking. It’s no accident that the term Lightning Service Provider resembles Internet Service Provider. They’re similar in that they both connect users to a wider network, but different networks require different functions from their service providers.

So let’s talk about those functions.

What does an LSP actually do?

Lightning is a network of nodes connected by payment channels. Those payment channels come with a number of features that both make the network secure and trustless as well as potentially cumbersome for new users. These features would include capacity limits, inbound and outbound liquidity, routing through payment channels from sender to receiver, the need to sync with the bitcoin mainnet, etc.

LSPs basically constitute counterparties on users’ payment channels that perform channel-management functions automatically in order to ensure that they work consistently and effortlessly from a user’s perspective. For example:

1. Opening channels

An LSP’s first function is to open a channel with a new user’s node and to confirm its active status. Since the channel is initiated and created by the LSP, the user doesn’t need to fund the channel herself from an existing on-chain wallet, which greatly simplifies the on-boarding process. LSPs can onboard fiat users directly, leapfrogging on-chain technology and flattening the learning curve.

2. Incoming capacity

When a user manually opens a channel, she cannot receive any payments until she spends some of the funds used to open the channel.

In an LSP model, where the LSP funds the channel from the outset, users benefit from immediate inbound capacity. While users will still have to deposit funds into the channel before they can spend anything, the LSP’s inbound capacity will let them receive funds immediately via Lightning once the channel is active.

3. Routing

LSPs act as hubs, providing users with a secure, stable connection to a node that itself is well connected with payment channels to further hubs and ensuring that users can always route payments where they please. LSPs’ connectivity is their capital.

Payment channels are invisible, so it’s easy to forget the importance of reliable routing. (Source: Edward Crompton)

4. Rebalancing

Hubs need open channels with each other to route payments. They also have local and remote balances, and if those balances fall out of … erm … balance, then they will no longer be able to forward users’ payments. A busy hub whose channels are all skewed toward the remote balances won’t be able to forward payments, and a hub receiving high volumes of incoming transfers will run out of channel capacity to accept any more.

Another vital LSP function, then, is rebalancing the distribution of funds in the local and remote balances among themselves to ensure the liquidity of their payment channels and the mobility of users’ funds.

5. Reliability

In order to avoid downtime, users can either open a range of different channels with different nodes in different locations and on different terms, or they can connect to just one or a few hubs who must provide reliable service to survive. The first strategy requires lots of management and lots of funds to be committed in different places, whereas the latter relies on the network’s built-in incentive structure to solve the problem.

Beyond uptime, there is also the more fundamental need to have open channels available at all. When push comes to shove, either node on a payment channel can (force) close it with little or no warning.

By providing users with rock-solid SLAs, LSPs can reassure users that they’ll be able to pay and get paid when they want without having to manage multiple channels and commit funds all over the network. And the SLAs reassure users that channel closures will only happen in predictable, well-defined circumstances.

LSPs without centralization

At first glance, there’s a tension between bitcoin’s decentralized, P2P, trustless nature and a network with hubs, isn’t there? If users connect to the network over a single hub, and payments are simply routed from one hub to another, it might sound like centralization.

But the network graph sure doesn’t *look* like centralization, does it? [Source: Wikipedia]

That’s not exactly true because it’s so easy to mitigate. Why should anyone connect to a single LSP? Why shouldn’t users have the option to have several LSPs available in their apps and be able to choose whichever offers the lowest transaction fees?

If we keep the barriers to entry low, and there’s a lively market of LSPs, users can hop between them to suit their own purposes. They need not rely on a single LSP, and the network would remain decentralized.

Although LSPs don’t require trust, ideally, users will run their own full nodes and essentially be their own LSP. For the less advanced users, public LSPs provide them with the choice they need to remain sovereign and autonomous.

LSPs help to onboard users, and Breez helps to onboard LSPs

Despite the fact that it’s a great business model open to virtually everyone, there are not many LSPs currently out there. Breez is one (very good) example. When users install the Breez app, we provide them with 1M satoshis of incoming capacity in channels the Breez hub opens for them automatically. Our hub is well-connected too: it actively rebalances funds on its payment channels to ensure liquidity with over 70 other hubs.

Bad lip reading: “One million satoshis! Bwahahaha!” (Source: tenor)

At the moment, Breez users automatically opt in to the Breez LSP. In the near future, though, we’ll be giving our users the option to select a different LSP within the app. They’ll still be able to use the Breez app with all its advantages, but they’ll be able to select the LSP(s) of their choice — including their own nodes.

Choice is good for users, competition is good for the market, decentralization is good for the network, and users are good for Breez. Everybody wins.

But we’re not the only LSP currently operating. There are a few others on the market providing users with funded channels and with more or less channel and balance management: LightningTo.Me, LNBIG.com, and Bitrefill’s Thor, for example. They’re all doing their part to onboard users and to expand the Lightning economy.

We’re actively proving the viability of the LSP model, and we welcome you to join us. If you operate your own LSP or are interested in getting one started but need users, contact us. We’d love to include you as an option in our Android and iPhone apps.

Let’s onboard the world to the Lightning economy.