Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Panic if we're running with outdated state instead of force-closing #1564

Merged
merged 2 commits into from
Jun 27, 2022
Merged

Panic if we're running with outdated state instead of force-closing #1564

merged 2 commits into from
Jun 27, 2022

Commits on Jun 25, 2022

  1. Add ChannelManager methods to force close without broadcasting 

    If a user restores from a backup that they know is stale, they'd
like to force-close all of their channels (or at least the ones
they know are stale) *without* broadcasting the latest state,
asking their peers to do so instead. This simply adds methods to do
so, renaming the existing `force_close_channel` and
`force_close_all_channels` methods to disambiguate further.
    @TheBlueMatt
    TheBlueMatt committed Jun 25, 2022
    Configuration menu
    Copy the full SHA
    5ed3f25 View commit details
    Browse the repository at this point in the history

  2. 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 lightningdevkit#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 lightningdevkit#1563.
    @TheBlueMatt
    TheBlueMatt committed Jun 25, 2022
    Configuration menu
    Copy the full SHA
    caa2a9a View commit details
    Browse the repository at this point in the history