Matt Corallo

Sorry I missed this comment, but, yea, its basically fundamental to lightning - if persistence fails we can't make progress on the channel. We could respond by FC'ing, but I'm...

Depending on the exact state that hit disk last (and in the future, not depending on anything), restarting should/would restore the channel to normal operation just fine.

Moving this to another release. I still think we should just wholesale remove the `ChannelMonitorUpdateStatus::UnrecoverableError` variant entirely but others seem to disagree. Even if we do that, though, maybe it...

I'm not sure I quite understand the desire to serialize this. We use it to keep track of things as we fetch them, but generally shouldn't ever need the cache...

> If it now goes offline, and a reorg happens in the meantime, lightning-block-sync might not have the necessary old header data around to call block_disconnected before re-connecting the blocks...

> Right, so if we want to be able to safely handle switiching chain sources, we need to at least support a minimal persisted cache (in LDK Node we restrict...

I'm a bit confused, though, the cache should really only be relevant when we're reorging, which shouldn't be common? Why is it a material performance difference?

Okay, but in this case we should probably persist a fixed-size cache of, let's say, 6 blocks (the depth that we assume no reorgs will happen), no?

I still really strongly disagree with the approach of persisting the cache. In the "performance improvement" case, we shouldn't be relying on downstream-of-LDK applications to fix `lightning-block-sync`'s performance issues. We...

> No, but the cache is immutable at that state on purpose to avoid essential entries being dropped (e.g., in case of a bounded cache) as we walk back to...