Matt Corallo caa2a9a55b Panic if we're running with outdated state instead of force-closing ... When we receive a `channel_reestablish` with a `data_loss_protect` that proves we're running with a stale state, instead of force-closing the channel, we immediately panic. This lines up with our refusal to run if we find a `ChannelMonitor` which is stale compared to our `ChannelManager` during `ChannelManager` deserialization. Ultimately both are an indication of the same thing - that the API requirements on `chain::Watch` were violated. In the "running with outdated state but ChannelMonitor(s) and ChannelManager lined up" case specifically its likely we're running off of an old backup, in which case connecting to peers with channels still live is explicitly dangerous. That said, because this could be an operator error that is correctable, panicing instead of force-closing may allow for normal operation again in the future (cc #1207). In any case, we provide instructions in the panic message for how to force-close channels prior to peer connection, as well as a note on how to broadcast the latest state if users are willing to take the risk. Note that this is still somewhat unsafe until we resolve #1563.		2022-06-25 02:25:32 +00:00
..
src	Panic if we're running with outdated state instead of force-closing	2022-06-25 02:25:32 +00:00
Cargo.toml	Update crate versions to 0.0.108/invoice 0.16	2022-06-10 14:53:23 +00:00