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.

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

Conversation

t-bast
Copy link
Collaborator

@t-bast t-bast commented Feb 24, 2020

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. (see the issue for a longer discussion)

This is an alternative to #740. I think it makes sense to dip into the reserve in that case.
Do note that this only fixes the stuck channel issue if the channel reserve is big enough for the fee increase.
At ~3500 sat/kw with a 1% reserve, it means that channels with a capacity bigger than 60 000 sats are safe from getting stuck, but smaller channels may still get stuck.

@t-bast t-bast changed the title Avoid stuck channels after fee increase Avoid stuck channels after fee increase by dipping into reserve Feb 24, 2020
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.
@@ -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.

@t-bast
Copy link
Collaborator Author

t-bast commented Mar 3, 2020

Closing in favor of #740 as agreed during yesterday's IRC meeting.

@t-bast t-bast closed this Mar 3, 2020
@t-bast t-bast deleted the stuck-channel-dip-reserve branch April 28, 2020 13:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Stuck channels because of small fee increase
2 participants