Brainstorming: How to prioritise blockchain state over local state

[thomaseizinger]

Being a blockchain-backed application, itchysats should always prioritize the blockchain state over its local state. Whilst this may be obvious, it is currently not the case.

For example, take #1617. Here, we had a state disparity after a rollover which led to subsequent rollovers failing and eventually a force-close by the taker with an old state. Due to punishment not yet being implemented, the maker was not able to punish. The taker successfully closed the CFD with a CET and marked it as closed. However, the maker doesn't know that because it stopped monitoring the old commit transaction and only triggers the (unimplemented) punish path.

Ideally, the application would recognise that the CFD has been closed through a different transaction and also mark it as closed, perhaps flagging somehow that this was unexpected so it can later be reviewed.

In summary, I am suggesting that we need to design some functionality that either reconciles local state with blockchain state or make it such that are aware of any possible blockchain state that can happen.

[thomaseizinger]

First priority should be to obviously fix all bugs so that these states can't occur. However, it turns out that implementing https://www.rfc-editor.org/rfc/rfc9225.html is quite tricky which is why we also made a decision on using regular housekeeping for such problems: https://github.com/itchysats/architecture/blob/main/decision-records/016-regular-housekeeping.md