Uh oh!
There was an error while loading. Please reload this page.
Fix two edge cases in handling of counterparty revoked commitment txn - #1486
Conversation
wpaulino
left a comment
There was a problem hiding this comment.
LGTM after rebase, nice catch and tests!
19f4f99 to
334c0c4CompareTheBlueMatt
commented
May 27, 2022
Reased after merge of #1481. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
334c0c4 to
032673cCompareCodecov Report
@@ Coverage Diff @@## main #1486 +/- ##
==========================================
+ Coverage 90.96% 91.80% +0.84%
==========================================
Files 80 80 Lines 43533 47809 +4276 Branches 43533 47809 +4276 ==========================================
+ Hits 39598 43892 +4294 + Misses 3935 3917 -18
Continue to review full report at Codecov.
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
032673c to
a9ad6f9CompareUh oh!
There was an error while loading. Please reload this page.
wpaulino
commented
Jun 13, 2022
@TheBlueMatt CI is failing now with |
4154c55 to
690817eCompareTheBlueMatt
commented
Jun 14, 2022
Oops, yea, needed to rebase on latest upstream changes. |
tnull
commented
Jun 14, 2022
LGTM, feel free to squash. |
Previously, while processing a confirmed revoked counterparty commitment transaction, we'd populate `OnchainEvent`s for live HTLCs with a `txid` source of the txid of the latest counterparty commitment transactions, not the confirmed revoked one. This meant that, if the user is using `transaction_unconfirmed` to notify us of reorg information, we'd end up not removing the entry if the revoked commitment transaction was reorg'd out. This would ultimately cause us to spuriously resolve the HTLC(s) as the chain advanced, even though we were doing so based on a now-reorged-out transaction. Luckily the fix is simple - set the correct txid in the `OnchainEventEntry`. We also take this opportunity to update logging in a few places with the txid of the transaction causing an event.
690817e to
9854c91CompareTheBlueMatt
commented
Jun 15, 2022
Squashed without changes: |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
When we see a counterparty revoked commitment transaction on-chain we shouldn't immediately queue up HTLCs present in it for resolution until we have spent the HTLC outputs in some kind of claim transaction. In order to do so, we first have to change the `fail_unbroadcast_htlcs!()` call to provide it with the HTLCs which are present in the (revoked) commitment transaction which was broadcast. However, this is not sufficient - because all of those HTLCs had their `HTLCSource` removed when the commitment transaction was revoked, we also have to update `fail_unbroadcast_htlcs` to check the payment hash and amount when the `HTLCSource` is `None`. Somewhat surprisingly, several tests actually explicitly tested for the old behavior, which required amending to pass with the new changes. Finally, this adds a debug assertion when writing `ChannelMonitor`s to ensure `HTLCSource`s do not leak.
7cd9ebf to
70ae45fCompareTheBlueMatt
commented
Jun 21, 2022
Rebased without change: |
Based on #1481 as the tests are only useful with it.Discovered while working on #1466.
This adds two new commits which correct some edge-case handling of revoked counterparty commitment transactions. They're both super duper edge, so not worth rushing too much to fix them, but will be needed for #1466 so would be nice to get them soon-ish.
The first case is only relevant for users disconnecting blocks with
transaction_unconfirmed, when the counterparty broadcasts a revoked commitment transaction, which is then reorg'd out and replaced with a non-revoked commitment transaction.The second case handles resolving HTLCs even though we haven't yet spent them, though we have broadcast the spend transactions and should spend them soon. This, too, is only relevant in case the revoked commitment transaction gets reorg'd out and replaced with a non-revoked one (and then the HTLCs claimed by our counterparty).