Correct handling of reorg'd-out revoked counterparty transactions
authorMatt Corallo <git@bluematt.me>
Tue, 17 May 2022 00:12:20 +0000 (00:12 +0000)
committerMatt Corallo <git@bluematt.me>
Wed, 15 Jun 2022 14:21:35 +0000 (14:21 +0000)
commit44d1dfa23dcb19be6f3a02f7e18b3b905c1d4683
tree90809acb82ff4bc94e0473a851d7be43c5784038
parent435680904aca29a5811e3eaaefc4cda8652ff87e
Correct handling of reorg'd-out revoked counterparty transactions

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.
lightning/src/chain/channelmonitor.rs
lightning/src/ln/reorg_tests.rs