How to spend all funds from a Lightning Channel
The protocol suggests to always keep some reserve, but if the parties mutually trust each other it may not necessary
Why cannot spend all the funds?
The Lightning Network Specifications define
channel_reserve_satoshis as the minimum amount that the other node is to keep as a direct payment. It also suggests the reserve value be 1% of the channel total value. “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.”
The reserve works as an insurance against possible theft attempts. If a peer tries to cheat by broadcasting an old channel state, its counterparty can submit a penalty transaction. This transaction takes away all fund on the channel from the misbehaving node as a punishment. And
channel_reserve_satoshis assure that every peer tends to have some reserve on the channel, at least 1%. This way in game theory every participant has incentive toward honest behavior. Because everyone has something to lose if trying to cheat.
Although it may a little bit strange, yet there is logic in it. But in some cases, this reserve may be rather annoying.
When I first tested Lightning payments, I just sent 1 satoshi from one peer to another. I was surprised when I realized I cannot send the same 1 satoshi back. Because even though the peer already had 1 satoshi on the channel, it was below the
channel_reserve_satoshis limit and the spendable amount was still zero.
For demonstration, I will start another Lightning Node besides to my main node. Then I will fund a channel between them and send 1 satoshi. Then check if it is unspendable because of the reserve limit. After that, I rewrite
channel_reserve_satoshis on the peer’s database and send that satoshi back.
Step One: Test Node setup
Step Two: Send a payment to the Test Node
Step Three: Reconfigure the channel reserve
Step Four: Sending the satoshi back
Lightning Network still in beta phase, it may contain a number of bugs.
What I described above is definitely not a common use case, not heavily tested. Maybe this is not a use case at all. I assume it should not be enough to reconfigure a peer itself for this. Peers might want to enforce their partners to keep some reserve. A peer probably should ask for its counterparty’s permission to spend all funds.
I only tested this between c-lightning v0.6 implementations. Other versions may behave differently.
Be patient! Be reckless!