Skip to content

Refactor Confirm interface around per-block changes #3867

Open
@tnull

Description

@tnull

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions