You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Only generate a post-close lock ChannelMonitorUpdate if we need one
If a channel is closed on startup, but we find that the
`ChannelMonitor` isn't aware of this, we generate a
`ChannelMonitorUpdate` containing a
`ChannelMonitorUpdateStep::ChannelForceClosed`. This ensures that
the `ChannelMonitor` will not accept any future updates in case we
somehow load up a previous `ChannelManager` (though that really
shouldn't happen).
Previously, we'd apply this update only if we detected that the
`ChannelManager` had not yet informed the `ChannelMonitor` about
the channel's closure, even if the `ChannelMonitor` would already
refuse any other updates because it detected a channel closure
on chain.
This doesn't accomplish anything but an extra I/O write, so we
remove it here.
Further, a user reported that, in regtest, they could:
(a) coop close a channel (not generating a `ChannelMonitorUpdate`)
(b) wait just under 4032 blocks (on regtest, taking only a day)
(c) restart the `ChannelManager`, generating the above update
(d) connect a block or two (during the startup sequence), making
the `ChannelMonitor` eligible for archival,
(d) restart the `ChannelManager` again (without applying the
update from (c), but after having archived the
`ChannelMonitor`, leading to a failure to deserialize as we
have a pending `ChannelMonitorUpdate` for a `ChannelMonitor`
that has been archived.
Though it seems very unlikely this would happen on mainnet, it is
theoretically possible.
0 commit comments