Compiled by: BTCStudy

Since its inception, the Lightning Network has grown significantly. Many optimizations have made the experience of Lightning payments smooth and seamless, but it is not without flaws. The user experience today may not be far from our goals, but as developers, we need to face this challenge: What can we do to improve the user experience?

In this article, we will explore what the user experience of the Lightning Network might look like based on the solutions being developed by many smart minds today.

First, let’s outline the current user experience and the pain points associated with it. Then, I will show how with the help of technologies that are being implemented and actively developed, the future of the Lightning Network could be.

What challenges will the Lightning Network face in 2023?

First, let’s address the elephant in the room: Today, a large portion of transactions on the Lightning Network are conducted through custodial wallets. Rough estimates suggest that close to 90% of transactions on the network are completed through applications where users need to trust a custodian to hold their private keys, based on Lightning transactions happening on the Nostr protocol.

Why do most users currently choose custodial services? It’s because of convenience, a simple user experience, and the challenges of using non-custodial Lightning wallets. We can categorize these challenges into three main areas:

Technical Ability

If users are forced to take more actions than traditional payment methods to achieve the same goal, most users will lose interest. For example:

Users must stay connected to send and receive payments. Today, a significant reason for failed Lightning payments is the recipient being offline, accounting for about 0.5% to 1% of all Lightning payments.
Users must share invoices with each other outside of the protocol, such as through text, email, instant messaging tools, etc., to initiate and request payments. This is a cumbersome process.
Users running their own Lightning nodes must be able to allocate Bitcoin across different channels. Opening a channel to an inactive peer node may result in funds being stuck there and not being utilized effectively.

This is the opportunity cost of capital on the Lightning Network: If your capital is allocated to an unresponsive peer node, it cannot be used to route payments (and generate revenue).

Technical Knowledge

These issues require users to have a deep understanding of the Lightning Network and/or unrelated protocols, which is not something ordinary Lightning Network users would pursue.

Setting up a Lightning node requires a certain level of technical ability. A Lightning node must always be online to maintain connections with the rest of the network.

If a user’s node goes offline, the Bitcoin in their channels may be lost or stolen.

A node operator must constantly balance liquidity between their channels. If you don’t have funds on your end of the channel, you cannot send payments; conversely, if all the funds in the channel are on your end, you cannot receive payments.
When a payment fails or is stuck, the node operator must be proficient in using the command-line interface to resolve the issue.
Backing up a node is complex—the node operator needs to store their seed phrase and channel state, or else existing channels may be closed if the connection is lost.

Technical Deficiencies

The technology of the Lightning Network has not been fully deployed yet. There are still some technical issues that need to be resolved.

We do not yet have a standardized and user-friendly technology that can directly send payments to anyone without relying on centralized servers.

Examples are a unified QR code or an experience like LianGuaiynym.
LNURL and Lightning address are options, but they also have drawbacks as they still rely on someone running a server somewhere.

Because a Lightning node must be online all the time, the signing key must also be online. This creates comprehensive security risks.
The cost of opening and closing channels is directly related to on-chain transaction fees. During periods of high demand for on-chain transactions, fees can rise rapidly, making the switching of channels expensive.

To avoid this, users must establish channels before the surge in fees, although it is not easy to decide when to open channels.

The privacy on the Lightning Network is not yet good enough.

When you request a payment on the Lightning Network, you must expose some information, such as the IP address of the node.
Although the sender (in general) has better privacy than the receiver, they also expose some information during the transaction process.
Based on the way Lightning nodes communicate with each other, third parties can easily determine the on-chain UTXOs related to their channel funding transactions. If such monitoring is carried out on a large scale, it may lead to the de-anonymization of the network.

(Translator’s Note: The problems described here by the author are all real, but most of them are not relevant to the ordinary user’s experience on the Lightning Network.

To use (trustless) Lightning payments, your Lightning node does not need to be online all the time. The self-custodial Lightning wallet you use (which is actually also a Lightning node) only needs to be online when receiving and sending payments;

In addition, you need to regularly open these wallet applications to ensure that your counterparty does not cheat you. The biggest challenges faced by ordinary users come from the above-mentioned points:

(1) Need to stay online when receiving/sending payments;

(2) Lack of a payment method that can receive arbitrary amounts multiple times (payment invoices are one-time only);

(3) Liquidity issues for incoming/outgoing transactions, i.e., if your counterparty has no balance in the channel, you cannot receive payments.

Currently, hosted wallets that support LNURL eliminate these problems for users, but the cost is that users have to trust the hosting provider. Wallets with LSP mainly help solve the third problem and have greatly improved the user experience (users do not need to manage channels themselves), but the solution to the first two problems still relies on technological advancements – spoiler alert: they can both be solved.

But speaking of it, the growth of the entire Lightning Network and the improvement of the user experience also rely on node operators being able to solve these pain points, because the Lightning Network is a network.

If most (not to mention all) of these problems can be solved, what will the Lightning Network look like?

The User Experience of the Lightning Network in 2025

Here, we want to emphasize the potential user experience of the Lightning Network. This is not a specific roadmap, but a prediction of the possible user experience after certain upgrades have been deployed in the future.

Channel splicing makes Lightning channels invisible to users

We expect that “channel splicing” will be implemented on most Lightning wallets in the coming years, but what does this mean for network participants?

First, node operators will be able to join funds to/from channels without paying excessive on-chain fees, and they don’t need to close and reopen channels (meaning they can maintain the normal operation of Lightning channels while injecting/removing funds). Because the operation of resetting channel capacity becomes cheaper, node operators – or automated software – can better control their channels, which in turn means a higher success rate for payments.

Lightning Service Providers (LSPs) can also benefit from the reduced (channel reset) costs and provide better user privacy. LSPs that attempt to optimize user privacy can pool users’ funds together and batch process channel reset transactions to obfuscate the source of funds.

When channel splicing becomes popular, the migration of funds between the Lightning Network and the Bitcoin chain will become cheap and easy, and wallets will display a unified balance – because users no longer need to distinguish between on-chain and off-chain funds.

When on-chain fees are high, LSPs can also manage users’ channels cheaply by combining splicing and atomic rebalancing on side chains (such as Liquid).

(Translator’s Note: The Phoenix mobile wallet already supports channel splicing; their developers have detailed the experience improvements this will bring to users.)

Lightning Service Providers reduce entry barriers

In the visible future, LSPs may become a key component of the user experience because they can help users hide complexity. In addition, LSPs can reduce the capital requirements for operating a node; they can serve as a gateway for users to enter the network.

The magic of the Lightning Network is its instant settlement capability, but failed payments and other pain points can weaken the user experience. Through infrastructure operated by LSPs, such as services and/or the nodes themselves, users can interact with the Lightning Network more directly. LSPs can eliminate the need for users to interact with the infrastructure by offering a “cloud-based node” mode, where users still control their funds but do not need to interact with that node. LSPs can also provide a “light” version of this service that consumes less power on mobile phones, or they can combine both modes.

If more capital is transferred to the Lightning Network, users must be able to recover their Lightning node (or Lightning wallet) in a similar way to recovering an on-chain wallet – for example, by entering a sequence of 12 or 24 words in the application. Service providers can allow users to store encrypted backups of their Lightning wallets in the cloud. When a user’s device is damaged or compromised, the encrypted cloud backup can be easily imported into a new device.

Eliminating manual operations

If someone has to take extra steps to benefit from Bitcoin (or any other magical technology), they are likely to give up on these steps.

There is currently a problem that needs to be solved: LSPs can solve the requirement of “staying online” by accepting payments for offline users, making the user experience closer to existing payment solutions.

As Bitcoin developers receive more funding support, more solutions will emerge that allow users to receive payments independently without relying on external services.

The payment IDs currently used, such as Lightning Address, are available but are supported by custodians almost all the time. Users need to be able to receive payments using reusable QR codes without relying on third parties. Reusability is crucial: copying, pasting, and sending invoices to payers involves too many steps. If there is a simple solution, all Lightning Network users can benefit from it.

In the above figure, a smaller and simpler QR code, called an “offer,” can allow the wallet to handle the invoice request part of the payment process without user guidance. Another advantage of the offer is that it can carry information such as currency, vendor name, quantity limits, and the path to reach the recipient’s wallet.

Many people prefer a simple onboarding process, which means they may prefer devices with trusted service providers. One example is the Fedimint protocol: a group of people manage something called an “e-cash mint.” This model provides better privacy and a range of additional products and services, such as estate management, private mining pools, decentralized dispute resolution, synthetic USD positions, and so on. Because the Lightning Network is built into these communities, users can leave and join different alliances based on their own judgment, with low migration costs.

Privacy is a standard feature in the Lightning Network

In order to make privacy a standard feature of the Lightning Network, the technology that achieves privacy must be hidden from users – meaning users do not need to take any action to benefit from it. Application developers and service providers must act behind the scenes, such as isolating on-chain transactions from Lightning transactions, and so on.

Interfering with surveillance in the Lightning Network

It will become very difficult to determine whether a transaction on the blockchain is a Lightning Network open/close transaction because new technologies are increasingly making them look no different from other Bitcoin transactions. With more implementations of Taproot technology, features like signature aggregation can hide information about a payment channel and possibly how many users are involved in the transaction. (Translator’s note: This is related to the Schnorr signature introduced by the Taproot upgrade. In certain conditions, it can aggregate the signatures of both parties in a channel into one signature, making it difficult for outsiders to distinguish this transaction from a regular personal wallet payment in the case of cooperative channel closure.)

If Taproot is widely implemented in wallets, users can have better privacy when paying to someone outside their peer nodes. Currently, such multi-hop payments have a payment ID (the hash value of the payment) that is known to every intermediate node on the forwarding path. However, certain ways of handling signatures in Taproot can be used to create “dummy” payment IDs that prevent forwarding nodes from seeing the full picture, so that only the sender and receiver have a clear understanding of the payment. (Translator’s note: This is also related to Schnorr signatures, and the relevant technology is called “PTLCs”, where the information obtained at each hop is different.)

Lightning Network users may no longer need to worry – or even know – the specific path their payment goes through. However, currently, every node on the entire path can see where the payment comes from (Translator’s note: This should be a misunderstanding, as intermediate nodes do not know the origin of the payment). In the “Canadian Freedom Convoy” incident, we can see that the government can and will seize funds, freeze fiat bank accounts, and even scrutinize those who oppose them.

LSPs can anonymize the source of a Lightning transaction by providing a service as an anonymizing routing intermediary. In this way, the LSP only knows the part of the payment path it has constructed, while the sender knows the other part; the intermediate nodes and the destination of the entire path are “blinded”. This model will provide stronger security, and users don’t need to be directly involved.

(Translator’s note: The author mentions the technique of “path blinding” here. Currently, the recipient of a Lightning payment must expose their network location to the payer so that the payer can find a payment path to reach them. The idea of “path blinding” is that the recipient can provide an entry point to a path that can reach themselves, thus concealing their true location. The payer only needs to find a path to reach this entry node. Therefore, contrary to the author’s understanding, blinding the path is more about protecting the recipient’s privacy. As for how much information the LSP knows, it depends on where the LSP is located on the path from the entry node to the recipient node.)

Using the Lightning Network as a Virtual Private Network

Wallets can creatively provide privacy-enhancing features. For example, wallets and LSPs can act as “invoice intermediaries” for users; the wallet creates an invoice and forwards it to an LSP, which then completes the payment. For the recipient, it appears as if the LSP made the payment to them; and relying on this, the sender gains better privacy without changing their familiar payment process. Tony Giorgio, co-founder of Mutiny Wallet, points out that this approach allows wallet users to hide among all users of this LSP.

Some Lightning Network users may want stronger privacy. Many cases of transaction mixing are proven methods to enhance privacy, but they require manual operation by users and may incur many on-chain fees. Because LSPs already operate servers, they are in a favorable position for coordinating transaction collaboration services for users. Service providers can create privacy-enhancing checkpoints: when users open or close channels, increase or decrease channel capacity (as described in the “Channel Splicing” section above), or do so when users pay for goods or services.

Lightning Network Boosts E-commerce

Suppliers can provide customers with a return period through Lightning payments. Customers can pay a special invoice at checkout, retaining the ability to “revoke” the transaction until the goods and services are delivered. This was not possible before.

Security is Key for Institutions

To enable more institutions to join the Lightning Network, it needs to be easy to transfer funds from offline, cold wallets to a Lightning channel. Taproot channels open up this use case without sacrificing security.

In addition, this allows institutions to store large amounts of funds on the Lightning Network more securely. They will be able to use custom hardware to protect themselves from the risks of wallet connectivity.

Conclusion

The Lightning Network has proven its usefulness in instant settlement payments – but we should be clear that it is not without flaws. However, network participants can remain optimistic about solving UX obstacles; some of the smartest developers are tirelessly working to enhance the user experience.

With more technical solutions and capital invested in the Lightning Network, LSPs may play a larger role in helping end users remove complexity. Technological advancements will also benefit self-custodial users and bring the entire network closer to a “just works” experience.

There are many exciting things happening on the Lightning Network; all predictions about the future in this article are based on solutions currently being developed. The more developers and businesses dedicate themselves to optimizing the user experience, the more participants and capital the network will attract, resulting in a better experience for everyone.

Like what you're reading? Subscribe to our top stories.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Lightning

Gambling Chain

Looking ahead to the Lightning Network in 2025 New prospects for enhancing privacy and convenience