Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow HTLC receiver to dip into channel reserve #1083

Closed
wants to merge 1 commit into from
+13 −4
Closed

Allow HTLC receiver to dip into channel reserve #1083

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 13 additions & 4 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand Down