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

Channel lockup corner case workaround #3500

Merged
merged 3 commits into from
Feb 11, 2020

Conversation

rustyrussell
Copy link
Contributor

This is a previously-discussed problem (as shown in lightning/bolts#728 ) but @m-schmoock wrote a proof-of-concept in #3498 so I am pushing a mitigation for the imminent release.

The funder pays the onchain fees: this keeps it simple. If the funder has spent all their funds, they obv. can't use the channel, but the fundee also cannot: most implementations will not add an HTLC if the funder could not afford the resulting fee (c-lightning included). If we were to loosen that, I'm not sure how other implementations would respond :(

The simplest workaround is to keep a little extra around if we're the funder. It's still possible to get into a state (particularly with fee changes) where we're stuck, but this makes it less likely.

@rustyrussell rustyrussell added channeld Optech Make Me Famous! Look! Look! Look! COOL NEW FEATURE! labels Feb 11, 2020
@rustyrussell rustyrussell added this to the 0.8.1 milestone Feb 11, 2020
Copy link
Collaborator

@ZmnSCPxj ZmnSCPxj left a comment

Choose a reason for hiding this comment

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

ACK 46bcf8a

* additional constraint when we're funder trying to add an HTLC: make
* sure we can afford one more HTLC, even if fees increase 50%.
*
* We could do this for the peer, as well, by rejecting their HTLC
Copy link
Collaborator

Choose a reason for hiding this comment

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

In this case the peer would have to be funder and us the fundee?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes.

@ZmnSCPxj
Copy link
Collaborator

Should we add the remote, no-onchain-feerate-change-needed test case made by @m-schmoock in #3498 as well? We would have to modify it to expect failure at the second drain attempt.

@rustyrussell
Copy link
Contributor Author

Should we add the remote, no-onchain-feerate-change-needed test case made by @m-schmoock in #3498 as well? We would have to modify it to expect failure at the second drain attempt.

I originally did that, but we have to change the numbers now it doesn't allow the second HTLC. Seemed cleaner to leave it as a POC unmerged, and have this fast generic one in-tree.

@rustyrussell
Copy link
Contributor Author

Trivial rebase, Changelog line added.

This is inspired by @m-schmook's ElementsProject#3498
except this is simply a two-channel version which probes for the amount.

Signed-off-by: Rusty Russell <[email protected]>
Extract out num_untrimmed_htlcs() from inside fee_for_htlcs(), and
remove unused view arg.

Signed-off-by: Rusty Russell <[email protected]>
@rustyrussell
Copy link
Contributor Author

Another trivial rebase, fix flake8 warnings.

@m-schmoock
Copy link
Collaborator

m-schmoock commented Feb 11, 2020

About the mitigation, adding a soft reserve related to fee makes sense. Some questions:

  1. About the fundee rejecting it's peer running into this situation, @rustyrussell can you elaborate how/why the founder 'gets upset' with us?

  2. How do we mitigate channels that are already in that state right now? Our software could check this and make a circular payment to unlock them on its own.

  3. We need to check that the meaning of 'spendable_msat' in listpeers will not be broken.

I will test try out this PR this evening...

@rustyrussell
Copy link
Contributor Author

rustyrussell commented Feb 11, 2020

Note we're overdue for the 0.8.1 release.

  1. If this code rejects the remote attempt to add an HTLC (i.e. incoming), channeld will close the channel for violating the protocol since the peer should not have tried to do that. If it rejects a local attempt (i.e. outgoing), channeld returns an error to lightningd; this is common (e.g. no capacity). We would need to add a new failure mechanism for remote, to say "they added it, but we need to immediately fail it" which is complex.

  2. Fixing channels already in this state is out of scope for this PR (and I don't think necessary, since it's a not been seen much in the wild?).

  3. Yes, I will need to fix that, good catch.

Much of the testsuite also broke. (Actually, testsuite caught #3 as well, thanks!)

Add new check if we're funder trying to add HTLC, keeping us
with enough extra funds to pay for another HTLC the peer might add.

We also need to adjust the spendable_msat calculation, and update
various tests which try to unbalance channels.  We eliminate
the now-redundant test_channel_drainage entirely.

Changelog-Fixed: Corner case where channel could become unusable (lightning/bolts#728)
Signed-off-by: Rusty Russell <[email protected]>
@cdecker
Copy link
Member

cdecker commented Feb 11, 2020

ACK dc3a718

@cdecker cdecker merged commit 86c28b2 into ElementsProject:master Feb 11, 2020

/* Now, how much would it cost us if feerate increases 50% and we added
* another HTLC? */
fee = commit_tx_base_fee(feerate + feerate/2, untrimmed + 1);
Copy link
Member

Choose a reason for hiding this comment

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

Cleanup: we should split out the feerate + feerate/2 into a separate variable.

@m-schmoock
Copy link
Collaborator

hm... that was quick :D
I will still do my tests this evening

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
channeld Optech Make Me Famous! Look! Look! Look! COOL NEW FEATURE!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants