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

Avoid stuck channels after fee increase by dipping into reserve #750

Closed
wants to merge 1 commit into from
Closed

Avoid stuck channels after fee increase by dipping into reserve #750

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
16 changes: 13 additions & 3 deletions 02-peer-protocol.md
View file
Original file line number Diff line number Diff line change
@@ -794,9 +794,15 @@ is destined, is described in [BOLT #4](04-onion-routing.md).
#### Requirements

A sending node:
- MUST NOT offer `amount_msat` it cannot pay for in the
remote commitment transaction at the current `feerate_per_kw` (see "Updating
Fees") while maintaining its channel reserve.
- if it is _responsible_ for paying the Bitcoin fee:
- MUST NOT offer `amount_msat` it cannot pay for in the remote commitment
transaction at the current `feerate_per_kw` (see "Updating Fees") while
maintaining its channel reserve.
- if it is _not responsible_ for paying the Bitcoin fee:
- MUST NOT offer `amount_msat` if the remote cannot pay the fee for the
updated commitment transaction at the current `feerate_per_kw` (see
"Updating Fees"). In that case the remote may temporarily dip into its
channel reserve to pay the fee, but only for one pending non-dust HTLC.
- 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.
@@ -863,6 +869,10 @@ seconds, and the protocol only supports an expiry in blocks.
specification; larger amounts are not necessary, nor wise, during the
bootstrap phase of the network.

The node _responsible_ for paying the Bitcoin fee should be allowed to dip into
its channel reserve to accommodate a fee increase, otherwise the channel may end
up in an unusable state (see [#728](https://github.com/lightningnetwork/lightning-rfc/issues/728)).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do nodes signal that they allow this? Older nodes wouldn't allow this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need to signal anything.

First case: sender is upgraded, receiver is not. The sender will send an HTLC that the receiver will reject (a non-upgraded sender wouldn't have sent that HTLC - the channel would be stuck). No big deal.

Second case: receiver is upgraded, sender is not. The sender will not send any HTLC, so the channel will be stuck. It's still possible to restore the channel by using below dust HTLCs until it's unblocked.


### 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.