Test punishing revoked outputs of post-anchor counterparty aggregated cross-transaction second-stage HTLC transactions

[ariard]

For context, see #1825 (comment)

Post-anchor, a counterparty can broadcast an aggregated second-stage HTLC transaction spending multiple revoked commitment transactions. Currently, our logic only assumes our counterparty aggregate HTLC transactions from a single revoked commitment transaction (combination of L3027 in channelmonitor.rs, L2693 in channelmonitor.rs and L3039 in channelmonitor.rs).

As discussed on IRC, tagging this as "Blocking Anchor". As the mishandling of the issue could lead to a loss of funds, and the correctness is dependent not only on ChannelMonitor and ChainMonitor implementation, we would better off to have extended testing of this processing flow.

Edit: the code is correct even if the comment is still wrong in the assumption that post-anchor all HTLC claims are coming from the same commitment transactions.

[TheBlueMatt]

I don't believe this is true, see responses on the linked comment.

[ariard]

Corrected, effectively we're good here as Wilmer as pointed out. Though note the cross-commitment aggregated HTLC-claim transaction is still something we need test coverage for, and also exercising the logic on testnet or whatever we're handling well the whole pipeline here.