Scaling bitcoin to billions of self-custodial users with the lightning network creates many new usability issues.
Some of those issues include:
liquidity and uptime requirements
channel management
routing
complex backups
Lightning services offered by third-parties aim to solve these issues.
This section covers two categories of lightning services: Lightning service providers (LSPs), which focus on onboarding and providing connectivity to lightning users, and lightning wallet servers, which provide additional services not relating to connectivity.
Internet service providers (ISPs) help users connect to the internet. Similarly, lightning service providers (LSPs) help users connect to the lightning network while maintaining self-custody.
They do this by being well connected in the network, opening channels, and offering inbound liquidity to users. They often charge a fee for their services.
You can learn more about how liquidity works on our liquidity page.
Some LSPs may also offer channel management, routing, backups, and other services, but these are not limited to being offered by LSPs.
To use lightning, a self-custodial user needs at least one payment channel. To send payments, this channel needs outbound liquidity, which the user usually provides. And to receive payments, this channel needs inbound liquidity, which needs to be provided by someone else.
Finding someone offering inbound liquidity and opening a channel with them can be difficult, especially for new users. LSPs provide inbound liquidity and open channels for users.
LSPs can alter how they open channels to achieve unique user experiences. These can come with additional trust or privacy trade-offs, so users should be made aware of these and be able to opt out if used.
Below we dive into the different ways an LSP can open a channel and the unique user experiences they can offer.
Channels are usually only funded on one side, meaning that initially, one party won’t be able to send, and the other won’t be able to receive.
A collaborative fund, previously called dual funding, allows both parties to contribute bitcoin to the channel. This means both parties can send and receive once the channel is open.
If a user tries to receive a payment without enough inbound liquidity, the payment will fail.
In these situations, an LSP can fix this with on-demand liquidity. They open a new channel with the user, giving the user enough inbound liquidity to receive the payment.
A user may only have on-chain bitcoin to fund their lightning wallet with. An LSP can allow users to open a channel using an on-chain payment with a swap.
LSPs will need to provide enough inbound liquidity to forward the payment to the user. They often provide more than the forwarded payment amount so the user can receive additional payments with the channel.
Opening a payment channel first requires an on-chain transaction to be confirmed, which leaves users having to wait to spend the bitcoin in their channel.
A zero-confirmation channel allows users to use the channel without it being confirmed on chain. This makes it faster to onboard users, though comes with trust that the LSP will not cancel the transaction after payments are made.
Channel open techniques can be combined in various ways for even more unique user experiences.
An example is combining a collaborative fund with a zero-confirmation channel open. This ensures that both users can send and receive instantly rather than wait for the new channel to be confirmed.
LSPs makes it easy for users to connect to and use lightning by offering inbound liquidity . There are various ways LSPs offer this service which range in complexity.
If your application uses an LSP, ensure users can switch, opt-out, or use multiple LSPs. This ensures they can choose the LSPs that have trade-offs they are comfortable with.
It also prevents everyone from using the same LSP, improving decentralization.
Once a user is connected to the lightning network, likely through an LSP, lightning wallet servers (LWS) offer services that make using lightning easier for users. LSPs sometimes offer LWS services as part of their offering but this is not exclusive to LSPs.
LWSs act as trust-minimized third parties, so when possible, users should be able to opt out and operate their lightning wallet manually.
Below are some LWS services and the user friction points they solve.
Payment channel states need to be backed up each time a payment is received or sent. Users can make these backups, though if done incorrectly or stored insecurely, users are at risk of losing their bitcoin.
An LWS backup service can automatically back up and store a user’s channel states whenever they are updated. Giving the user the option to encrypt their backup prevents the LWS from stealing funds.
Non-freezability
Backing up your lightning wallet with a single LWS breaks non-freezability, meaning they can refuse to hand over your channel states when recovering.
A lightning address LWS service gives users a human-readable address that can be re-used to receive lightning payments. An example is bosch@bitcoin.design.
Non-custodial lightning wallets need to be online to receive payments. Daily spending wallets, in particular, are regularly offline, so receiving payments can be difficult.
LWSs can hold onto a payment (without assuming custody) and forward it to the user once they come online. A product that offers this for users is Greenlight.
This service is usually required to be offered alongside an LSP. Read more about this here.
A lightning wallet must be online on a regular basis to track it’s payment channels for cheating attempts. A daily spending wallet, in particular, is offline whenever the user stops using the app. This means there is a greater risk of cheating attempts.
A watchtower service can fix this. Watchtowers monitor the payment channels of offline users. If a counterparty attempts to steal a user’s funds, the watchtower can step in to help. The watchtower can prevent the theft by submitting a justice transaction.
Using watchtowers
It’s best practice to use a watchtower that is not controlled by the user’s LSP. This way, the watchtower has no incentive to cheat the user.
Multiple watchtowers can be used to limit the chances a users counterparty will collude with the watchtower.