UX guidance for LN channel reserve

[moneyball]

I searched the guide for "reserve" and came up empty. The guide should provide UX guidance for when and how to describe LN channel reserves to users. Users might fund a channel/wallet with X but then only be able to spend X-R where R is the reserve. This can be very confusing for users.

[GBKS]

Here's an article that includes an explainer on what the reserve is.

[mouxdesign]

I'd like to contribute to this one as well.

[mouxdesign]

This is a proposal for issue #659 to add information about UX Guidance for LN channel reserve;
https://docs.google.com/document/d/1gyMGtWqXS3NvxKAYUeMmd7NHhDRVnlKBz7EK3RZRWzs/edit?usp=sharing

WHAT IS A CHANNEL RESERVE?

The bitcoin protocol suggests that it is always important to keep some reserve. This is often called the channel reserve, it is an amount that will be held in a channel.
Lets say a user opens a channel and puts in 100k sats. When they then want to make payments they will then only have access to X - Y ;(the amount they added to the channel) - (1% minimum of the total channel value).

As an example;
If the total channel value is 200k sats, 1% of this is 2k sats. This is the amount that will automatically be held as a reserve.
If a user opens a channel and puts in 100k sats and we now need to calculate what amount they would actually have access to make payments with, then that would then be;
100k sats - 2k sats = 98k sats

For users we can imagine that they would now question why when they put 100k sats into a channel that only 98k sats would then be available for them to use.
Also according to the bitcoin protocol the channel reserve must be greater than or equal to the dust limit. The dust limit as of today is 354 sats

WHY DO WE HAVE A CHANNEL RESERVE?

A channel reserve works as a type of insurance against theft. If a peer tries to cheat in a channel then the other party can submit a penalty transaction. This transaction will then take away all the funds from the other users channel. Having the channel reserve in place that there are funds available to take away should this occur.

AFFECT OF CHANNEL RESERVE ON USERS:

If a user funds a channel and they are unable to spend the full amount they have put into the channel this can be confusing to them.

From a UX standpoint we would need to consider the following:

• Adding funds: Ensure that the user is educated when they are adding funds, so that they know that a small amount will be held as a reserve.

• Multiple channels: If a user has 20+ channels and their locked reserve will be 20 times that amount

• On boarding: During onboarding when a user opens their first channel and when trying to send all their funds

Below are some suggested screen states as to how this can be done: (to be added)

[Bosch-0]

Some context to what a channel reserve is to anyone reading, from BOLT 2:

The channel reserve is specified by the peer's channel_reserve_satoshis: 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially, this reserve may not be met, as only one side has funds; but the protocol ensures that there is always progress toward meeting this reserve, and once met, it is maintained.

When regularly opening channels with random nodes, having a reserve is important. Routing nodes do this often, mobile lite nodes do not. Mobile nodes usually only open channels with the LSP that their wallet uses. Mobile nodes usually only have a single peer (the LSP) who is known to them. When using an LSP, incentives (or their is trust) are often aligned between them and the user. This changes the trust-model and makes things like having a channel reserve less important for mobile nodes.

Channel reserves are something that only non-mobile node operating users should have to deal with. They add a lot of UX issues for mobile node end users who just want to make payments and mostly aren't necessary when using a Lightning Service Provider (LSP) trust-model.

Zero-reserve mobile node channels can be classified as a lightning service, something offered by a LSP. This service has been used in Phoenix since 2019. This isn't proof it's secure, but it most likely is isn't a protocol breaking change. When zero-reserve is used the LSP should still use a reserve as Phoenix / ACINQ does so they have something at stake. This is an asymmetrical incentive in favor of the mobile node user but other aspects of this setup explained below balance this out.

There are obvious UX improvement of having end users use zero-reserve. Not being able to spend your full balance will confuse a lot of users and having to explain why to users is a big mental burden for someone who just wants to simply make payments. However, this comes with some asymmetrical trade-offs, some in favor of the LSP, some in favor of the mobile node. I've attempted to address these trade-offs in my questions below.

Be sure to read this article for a deeper dive on the trade-offs around using zero-reserve.

Couldn't the mobile node easily cheat the LSP without anything at stake?

LSP nodes are often highly monitored / managed meaning it is very unlikely a mobile node would be successful in cheating the LSP by broadcasting an old state. LSPs could also use third-party watchtowers (they likely do) for further protection from cheating attempts.

Mobile nodes still have to pay for the channel opening, and sometimes an additional LSP service fee on top, so an attack of this kind isn't completely zero-stakes. The 1% reserve isn't a huge deterrent from cheating anyways imo - but this is a protocol dev discussion out of the scope of this issue.

Mobile nodes benefit from the services offered by the LSP which would also deter cheating as they have an incentive to keep using the services.

For these reasons, this is unlikely.

What about the LSP cheating the mobile node user?

This is more likely to occur than the mobile node cheating the the LSP - but is also unlikely. Mobile nodes are customers to LSPs so cheating them is not in their interest. LSPs earn fees from offering services / routing payments for mobile nodes. Their long term acquisition is most likely more profitable than exit scamming users which would likely forever ruin their reputation / kill their business model. This would also likely kill their routing node as network peers wouldn't want to support a dishonest node. Shutting down a routing node / re-allocating all that capital is expensive.

Users should have the option to use third-party (not the LSP) watchtowers as well as have some kind of in-built push notification system prompting the user to check their app / look for old channel states being broadcast.

What if a user manually opens a channel?

This should be an 'advanced' option for any bitcoin lightning payments app, users should not be locked into using an LSP! When manually opening a channel a local channel reserve should be used in this situation. For this scenario, this should be explained to the user as @Mogashni has pointed out above.

Side note: With Zeus, we are working on a mobile node (late 2022) using an LSP. Manual channel opens will only be for users who run their own node - which you can connect as a separate profile alongside your mobile node LSP payments profile. Mobile nodes using LSPs, combined with opening channels in the same UI results in a messy UX (I've tried to combine the two). Manually opening channels should only be done if you run your own always on node. Mobile nodes are not always online and peers will likely close your channels. Using autopilot doesn't solve this. Just my 2c on this.

How should content be added around this in the guide?

• Add content around zero-reserve lighting service usage in funding a wallet and eventually the receiving bitcoin page once that is live.
• Add content around how to explain channel reserve to users when they manually open a channel (I'm torn on this one, will be making a post around focusing the daily spending wallet stuff ONLY on using LSPs).
• My LSPs page is about to go live, of which I'll have a section on zero-reserve service with some details.

[sbddesign]

@Mogashni thanks so much for taking this issue on!

I left some comments on your Google Doc. I'll summarize here. In general, I agree with the notion that perhaps channel reserve is not necessary for nodes running on mobile devices. The tl;dr is that a channel reserve by itself will not protect that mobile node, so it needs a watchtower. Thus, the better UX might be to simply rely on the watchtower for protection. We're not at that glorious future yet where powerful, easy-to-use watchtowers are a dime-a-dozen, but I think that's likely the best approach.

Having said that, we should include this information on how to communicate channel reserve in situations where it must be communicated. I think some visuals will help explain this a lot.

[mouxdesign]

@sbddesign @Bosch-0 @GBKS Really appreciate your comments around the UX guidance explanation. I've updated the google doc and tried to incorporate as much of your comments as possible.

https://docs.google.com/document/d/1gyMGtWqXS3NvxKAYUeMmd7NHhDRVnlKBz7EK3RZRWzs/edit?usp=sharing

What I still need to do:

1. Read paragraph from BOLT2 provided by Bosch above and see what can be incorporated from there

2. Finish UI suggested designs; I've created some flow diagrams for these which I would love your input on. Its more about how to find UI opportunities to explain the channel reserve to users. The current UI images are actually taken straight from the Blixt wallet designs done by Stephen and Mili. So these will be redesigned/updated using the bitcoin ui kit. Right now I am just trying to understand where in the user flow the opportunities lie for educating users about the channel reserve (watchtower explanation would also need to come in here or be linked)

The UX opportunites could be during;

1. On boarding process 2) Opening a channel 3) Lightning channels overview tab (which is what Blixt does)
   https://www.figma.com/file/uOJxwErscsaVtkuSY0tLeV/Channel-Reserve-User-flow?node-id=0%3A1

[mouxdesign]

Updated the explanation based on the paragraph provided by Bosch. UI designs will be finished soon.
https://docs.google.com/document/d/1gyMGtWqXS3NvxKAYUeMmd7NHhDRVnlKBz7EK3RZRWzs/edit?usp=sharing

WHAT IS A CHANNEL RESERVE?
The Lightning protocol suggests that it is mandatory to keep some reserve. This is often called the channel reserve, it is an amount that will be held in a channel.
To use an example to illustrate; If
X = Amount put into channel
Y = Channel reserve amount

Lets say a user opens a channel and puts in 100k sats. When they then want to make payments, they will then only have access to X - Y; (the amount they added to the channel) - (1% minimum of the total channel value).
As an example;
If the total channel value is 200k sats, 1% of this is 2k sats. This is the amount that will automatically be held as a reserve.
If a user opens a channel and puts in 100k sats and we now need to calculate what amount they would actually have access to make payments with, then that would then be;
100k sats - 2k sats = 98k sats
For users we can imagine that they would now question why when they put 100k sats into a channel that only 98k sats would then be available for them to use.

CHANNEL RESERVE AMOUNT
Also according to the Lightning protocol the channel reserve must be greater than or equal to the dust limit. The dust limit as of today is 354 sats.
BOLT 2 has defined that the channel reserve amount should be equal to 1%. The 1% used in the above explanation is an illustrative amount and is not a fixed amount. In some cases since 1% is such a small amount, it may seem arbitrary to users with a smaller amount of funds in the channel. Whereas if a user has a larger amount in the channel, then the reserve amount being held has a greater effect on them especially if they want to use all the funds they placed in the channel straight away.

WHY DO WE HAVE A CHANNEL RESERVE?
A channel reserve works as a type of insurance against theft. If a peer tries to cheat in a channel then the other party can submit a penalty transaction. This transaction will then take away all the funds from the other user's channel. Having the channel reserve in place ensures that there are funds available to take away should this occur.
Each side of a channel maintains the channel reserve, and the protocol ensures that there is always progress being made towards meeting this reserve amount.

MOBILE NODES AND NON-MOBILE NODES
Mobile nodes will usually open their channels with the same LSP that their wallet uses. This changes the trust model as the user then trusts that the auto-selected method is the best/safest one. And so a channel reserve becomes less important.
Non-mobile node operating users should be the primary use case for channel reserves. This would be the case of a regular channel being opened with a random node, in this case a channel reserve is important.
Nodes are free to pick the reserve value at the channel start, but it cannot be changed. Each node picks the others’ reserve value - ie Alice cannot spend the amount that Bob tells her not to.

AFFECT OF CHANNEL RESERVE ON USERS:
If a user funds a channel and they are unable to spend the full amount they have put into the channel this can be confusing to them.
From a UX standpoint we would need to consider the following:
Adding funds: Ensure that the user is educated so that

1. When they are adding funds they know that a small amount will be held as a reserve.
2. They understand that although they cannot spend 100% of their balance they still own all of their funds. This is so that they understand that the channel reserve amount is not gone.
   Multiple channels: If a user has 20+ channels, then their locked reserve will be 20 times that amount
   Onboarding: During onboarding when a user opens their first channel and when trying to send all their funds
   In general the channel reserve itself adds on an additional layer of complexity to mobile users who just want to make payments.

There are however other, much more fool-proof ways to prevent theft such as ;

1. Using watchtowers
2. Ensuring users regularly check their apps.
   For nodes running on mobile devices a channel reserve by itself will not fully protect that mobile node and users would need a watchtower.
   Below are some suggested screen states as to how this can be done: (to be added)

[Bosch-0]

Awesome! This is looking good Mo, few comments!

The Lightning protocol suggests that it is mandatory to keep some reserve.

It's speced in BOLT 2 but it's not mandatory across the board - lightning protocol stuff is messy atm 😆 These things also become flexible when dealing with LSPs on a peer, rather than, network level.

If the total channel value is 200k sats, 1% of this is 2k sats.

A note on this section, which you did mention lower down but wanted to add some detail, is that this 1% is dynamically adjusted over the channels lifespan. So if this 200k sats channel receives 50,000 sats this reserve will adjust to 2,500. This adds further complexity for users as it will look like they are constantly losing sats. Compound this with if the user has lots of channels this dynamic adjusting will be all the over place.

Also you have a channel capacity which is both sides of the parties combined. Both sides independent have a channel reserve. So if my side is 200,000 sats mine will be 2,000, other parties is 100,000 sats they will have 1,000 reserve for a total channel wide reserve capacity of 3,000.

I included a small mock-up below of a toggle that could be used for showing channel reserve / actual spendable balance. This design is mostly focused on pending on-chain transactions atm though, some added detail would be needed to account for channel reserve nuances (as the available balance will never not be higher, increase with new channels, and dynamically change as mentioned above).

[mouxdesign]

Updated Figma file on UI opportunities for the channel reserve:
https://www.figma.com/file/6iJpftEbajA3y1ylXQxsrl/Channel-management-flow?node-id=0%3A1

Updated google doc:
https://docs.google.com/document/d/1gyMGtWqXS3NvxKAYUeMmd7NHhDRVnlKBz7EK3RZRWzs/edit?usp=sharing

[sbddesign]

Left feedback on Google Drive and Figma.

[GBKS]

Sharing an exploration from a while back. The idea was to have a dedicated screen to let the user quickly see what fees and their current limits are. Added a "minimum balance" which would be the channel reserve. I miss something like this from Muun, which has no way to learn about fees. The third screen shows how some of this info could be shown in context and only when needed. Will be important to identify those points to keep the overall experience simple.

[mouxdesign]

Almost there! The figma file has been updated and simplified alot based on the amazing feedback from you guys. Any other feedback is most welcomed.
https://www.figma.com/file/6iJpftEbajA3y1ylXQxsrl/Channel-reserve?node-id=0%3A1

[mouxdesign]

Updated Google doc, perhaps to be added at the bottom of Stephens liquidity page;

Link