Repository navigation
[feature]: Ability to remove channel reserve #8429
Description
Is your feature request related to a problem? Please describe.
Channel reserve is a major UX problem when working with mobile wallets. It would be very helpful to be able to remove it completely.
Describe the solution you'd like
Right now you can set remote_chan_reserve_sat when opening a channel but it can only go as low as the dust limit and I understood recently that 0 values in protobuf means default will be used. We could have a separate conf file setting called disable-remote-chan-reserve or a separate Boolean flag in the rpc that can disable the reserve and override remote_chan_reserve_sat.
Describe alternatives you've considered
Going as low as the dust limit. But it doesn't solve the issue.
Activity
ProofOfKeags commentedon Jan 25, 2024
Can you explain why having a value lower than the dust limit would fix your UX problems? We can't (shouldn't?) create an output that is lower than the dust limit, but maybe you're suggesting that there is no remote output in that scenario.
niteshbalusu11 commentedon Jan 25, 2024
I am saying allowing for complete removal of reserve will fix the problem. I don't think we should go below the dust limit. It should be 0 or dust to 20% (the way it is today)
Here are some things allowing for removal of reserve helps with:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004136.html
saubyk commentedon Jan 31, 2024
Shouldn't this be addressed at the spec level?
niteshbalusu11 commentedon Jan 31, 2024
I don't think so. We are already allowing configuration to bring it down to dust level. And it's only remote channel reserve that we are changing.
ProofOfKeags commentedon Jan 31, 2024
Technically this does have to be addressed at the spec level. There is a protocol level requirement that this is set to a value that exceeds the dust limit, however I do think we can come up with a well-defined way to adjust the spec to accommodate this. @t-bast has already expressed a desire to allow for negotiating a 0sat channel reserve.
niteshbalusu11 commentedon Jan 31, 2024
This is a little confusing to me. It makes sense if we say me as the opener doesn't want to have a reserve so the peer I am opening to might have a problem with it. In our case, the opener is saying to the peer, you can have 0 zero reserve. There is no reason for the peer to be unhappy about this. The peer would love it.
ProofOfKeags commentedon Jan 31, 2024
I don't disagree with you, but if the spec prohibits it, we need to fix it at the spec level. We can't just change it in LND without coordinating with other actors.
ProofOfKeags commentedon Jan 31, 2024
I just opened a PR against the spec to relax this, I expect there to be some debate but I think there's a decent chance this will get some traction. Note also that this is also being discussed as an extension and may find traction there. I'll follow the discussion and once there's an answer at the spec level we can proceed with an implementation plan in LND.
t-bast commentedon Feb 1, 2024
I have indeed published this blip to detail how that can be done, and is similar to how we do it for Phoenix. I believe this is very useful to mobile wallets, and it works well in practice.
Slaaavo commentedon Feb 26, 2024
Hello, I think it would make sense for this to be a property of the channel where both peers agree on the reserve on both sides. Right now, we're trying to cooperatively close a channel with a peer. The channel has almost all balance on my side, so we tried to completely push it to me, but failed to do so due to the 1% reserve. It would help us if we could simply agree to remove the reserve and then close the channel.
Roasbeef commentedon Feb 26, 2024
Modifying this issue to be the tracking issue for: lightning/bolts#1140
litbot-9000 commentedon Feb 21, 2026
Closing as duplicate of #5485 which tracks the ability to bypass/remove channel reserve requirements.