Channel lockup corner case workaround #3500
Conversation
rustyrussell
added
channeld
Optech Make Me Famous!
| * 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 |
There was a problem hiding this comment.
In this case the peer would have to be funder and us the fundee?
|
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
force-pushed
the
guilt/pr-3498
branch
from
46bcf8a
to
5f94c04
Compare
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
force-pushed
the
guilt/pr-3498
branch
from
5f94c04
to
c56b700
Compare
|
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
force-pushed
the
guilt/pr-3498
branch
from
c56b700
to
2eecba0
Compare
|
Another trivial rebase, fix flake8 warnings. |
|
About the mitigation, adding a soft reserve related to fee makes sense. Some questions:
I will test try out this PR this evening... |
|
Note we're overdue for the 0.8.1 release.
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]>
rustyrussell
force-pushed
the
guilt/pr-3498
branch
from
2eecba0
to
dc3a718
Compare
|
ACK dc3a718 |
|
|
||
| /* 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); |
There was a problem hiding this comment.
Cleanup: we should split out the feerate + feerate/2 into a separate variable.
|
hm... that was quick :D |
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.