Skip to content

Commit 6773120

Browse files
committed
Avoid stuck channels after fee increase
Allow funders to dip into their channel reserve once to be able to pay the increased commit tx fee for a pending HTLC. This prevents channels from getting in a state where the channel is unusable because of the increased commit tx cost of a new HTLC. Fixes #728.
1 parent dcbf858 commit 6773120

File tree

1 file changed

+13
-3
lines changed

1 file changed

+13
-3
lines changed

02-peer-protocol.md

+13-3
Original file line numberDiff line numberDiff line change
@@ -794,9 +794,15 @@ is destined, is described in [BOLT #4](04-onion-routing.md).
794794
#### Requirements
795795

796796
A sending node:
797-
- MUST NOT offer `amount_msat` it cannot pay for in the
798-
remote commitment transaction at the current `feerate_per_kw` (see "Updating
799-
Fees") while maintaining its channel reserve.
797+
- if it is _responsible_ for paying the Bitcoin fee:
798+
- MUST NOT offer `amount_msat` it cannot pay for in the remote commitment
799+
transaction at the current `feerate_per_kw` (see "Updating Fees") while
800+
maintaining its channel reserve.
801+
- if it is _not responsible_ for paying the Bitcoin fee:
802+
- MUST NOT offer `amount_msat` if the remote cannot pay the fee for the
803+
updated commitment transaction at the current `feerate_per_kw` (see
804+
"Updating Fees"). In that case the remote may temporarily dip into its
805+
channel reserve to pay the fee, but only for one pending non-dust HTLC.
800806
- MUST offer `amount_msat` greater than 0.
801807
- MUST NOT offer `amount_msat` below the receiving node's `htlc_minimum_msat`
802808
- MUST set `cltv_expiry` less than 500000000.
@@ -863,6 +869,10 @@ seconds, and the protocol only supports an expiry in blocks.
863869
specification; larger amounts are not necessary, nor wise, during the
864870
bootstrap phase of the network.
865871

872+
The node _responsible_ for paying the Bitcoin fee should be allowed to dip into
873+
its channel reserve to accomodate a fee increase, otherwise the channel may end
874+
up in an unusable state (see [#728](https://github.com/lightningnetwork/lightning-rfc/issues/728)).
875+
866876
### Removing an HTLC: `update_fulfill_htlc`, `update_fail_htlc`, and `update_fail_malformed_htlc`
867877

868878
For simplicity, a node can only remove HTLCs added by the other node.

0 commit comments

Comments
 (0)