From cc232a84e69632588407331dd7cef4d2ad83ce28 Mon Sep 17 00:00:00 2001 From: t-bast Date: Mon, 22 May 2023 16:28:04 +0200 Subject: [PATCH] Allow HTLC receiver to dip into channel reserve When an HTLC is added, the size of the commitment transaction increases while that HTLC is pending, which also increases the on-chain fee that the channel initiator must deduce from its main output. Before sending an HTLC, when we're not the channel initiator, we thus must ensure that our peer has enough balance to pay for the increased commitment transaction fee. We previously went further than that, and also required that our peer stayed above their channel reserve. That additional requirement was unnecessary, and there was no matching receiver-side requirement, so it should be safe to delete. It makes a lot of sense to allow the HTLC receiver to dip into its channel reserve to pay the fee for an HTLC they're receiving, because this HTLC will either: - be failed, in which case the balance goes back above channel reserve - be fulfilled, in which case the balance increases which also helps meet the channel reserve This also prevents channels from being stuck if the reserve becomes dynamic (which will be the case with splicing). Without that change, we can end up in a situation where most of the channel funds are on the non-initiator side, but they cannot send HTLCs because that would make the initiator dip into their reserve to pay the increased fee. Since this effectively shrinks the channel initiator's reserve, the sender must ensure that the resulting reserve is still large enough to incentivize the initiator to behave honestly (for example by allowing only X% of the channel reserve to be used for fees). --- 02-peer-protocol.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index f43c68611..d32b7d285 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -1015,10 +1015,11 @@ A sending node: buffer" can handle twice the current `feerate_per_kw` to ensure predictability between implementations. - if it is _not responsible_ for paying the Bitcoin fee: - - SHOULD NOT offer `amount_msat` if, once the remote node adds that HTLC to - its commitment transaction, it cannot pay the fee for the updated local or - remote transaction at the current `feerate_per_kw` while maintaining its - channel reserve. + - MAY offer `amount_msat` where, once the remote node adds that HTLC to its + commitment transaction, it goes below its channel reserve to pay the fee for + the updated local or remote transaction at the current `feerate_per_kw`. The + sending node should limit how much of the channel reserve can be used to pay + the fee to ensure that the receiving node always has some funds at stake. - MUST offer `amount_msat` greater than 0. - MUST NOT offer `amount_msat` below the receiving node's `htlc_minimum_msat` - MUST set `cltv_expiry` less than 500000000. @@ -1094,6 +1095,14 @@ maintaining its channel reserve (because of the increased weight of the commitment transaction), resulting in a degraded channel. See [#728](https://github.com/lightningnetwork/lightning-rfc/issues/728) for more details. +When the node _responsible_ for paying the Bitcoin fee is below or just +slightly above its channel reserve, the other node may allow it to dip +into the channel reserve to pay the fee for an incoming HTLC. This is +effectively the same as temporarily shrinking the channel reserve. The +node _not responsible_ for paying the Bitcoin fee must ensure that the +effective channel reserve is still large enough to incentivize the other +node to behave honestly. + ### Removing an HTLC: `update_fulfill_htlc`, `update_fail_htlc`, and `update_fail_malformed_htlc` For simplicity, a node can only remove HTLCs added by the other node.