Description
Currently, Confirm
allows to call best_block_updated
/transactions_confirmed
/transaction_unconfirmed
to be called independently, and even without prescribing concrete ordering requirements for the former two.
This can lead to indeterministic behavior/races. For example, we got a user report of a newly opened channel being force-closed with ClosureReason::FundingTimeOut
, if the node would restart past the 2016 blocks timeout described in BOLT 2, because lightning-transaction-sync
calls best_block_updated
before transactions_confirmed
.
While we could fix this particular race as a one-off, the real fix is a refactoring of Confirm
to only take a single best_block_updated
(or apply_block_changes
) method that would take an UpdatedBlock
object describing all the changes that happend as part of a particular block. We should then internally make sure that these changes are applied exactly in the order they need to be.