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
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.
returnErr(ChannelError::Close("Peer sent a garbage channel_reestablish with secret key not matching the commitment height provided".to_owned()));
3825
3828
}
3826
3829
if msg.next_remote_commitment_number > INITIAL_COMMITMENT_NUMBER - self.cur_holder_commitment_transaction_number{
3827
-
returnErr(ChannelError::CloseDelayBroadcast(
3828
-
"We have fallen behind - we have received proof that if we broadcast remote is going to claim our funds - we can't do any automated broadcasting".to_owned()
log_and_panic!("We have fallen behind - we have received proof that if we broadcast our counterparty is going to claim all our funds.\n\
3837
+
This implies you have restarted with lost ChannelMonitor and ChannelManager state, the first of which is a violation of the LDK chain::Watch requirements.\n\
3838
+
More specifically, this means you have a bug in your implementation that can cause loss of funds, or you are running with an old backup, which is unsafe.\n\
3839
+
If you have restored from an old backup and wish to force-close channels and return to operation, you should start up, call\n\
3840
+
ChannelManager::force_close_without_broadcasting_txn on channel {} with counterparty {} or\n\
3841
+
ChannelManager::force_close_all_channels_without_broadcasting_txn, then reconnect to peer(s).\n\
3842
+
Note that due to a long-standing bug in lnd you may have to reach out to peers running lnd-based nodes to ask them to manually force-close channels\n\
3843
+
See https://github.com/lightningdevkit/rust-lightning/issues/1565 for more info.");
ChannelError::CloseDelayBroadcast(_) => {panic!("Wait is only generated on receipt of channel_reestablish, which is handled by try_chan_entry, we don't bother to support it here");}
} else if let MessageSendEvent::BroadcastChannelUpdate { .. } = msg {
7498
+
if let MessageSendEvent::BroadcastChannelUpdate { .. } = msg {
7487
7499
} else if let MessageSendEvent::HandleError { ref action, .. } = msg {
7488
7500
match action {
7489
7501
&ErrorAction::SendErrorMessage { ref msg } => {
7490
-
assert_eq!(msg.data, "We have fallen behind - we have received proof that if we broadcast remote is going to claim our funds - we can't do any automated broadcasting");
7502
+
assert_eq!(msg.data, "Channel force-closed");
7491
7503
},
7492
7504
_ => panic!("Unexpected event!"),
7493
7505
}
7494
7506
} else {
7495
-
panic!("Unexpected event")
7507
+
panic!("Unexpected event {:?}", msg)
7496
7508
}
7497
7509
}
7498
7510
7499
-
// Check we close channel detecting A is fallen-behind
7500
-
// Check that we sent the warning message when we detected that A has fallen behind,
7501
-
// and give the possibility for A to recover from the warning.
let mut node_txn = nodes[1].tx_broadcaster.txn_broadcasted.lock().unwrap().clone();
7508
-
// The node B should not broadcast the transaction to force close the channel!
7509
-
assert!(node_txn.is_empty());
7510
-
// B should now detect that there is something wrong and should force close the channel.
7511
-
let exp_err = "We have fallen behind - we have received proof that if we broadcast remote is going to claim our funds - we can\'t do any automated broadcasting";
0 commit comments