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
Drop the (broken) ability to disable broadcast when FC'ing a chan
`ChannelManager` has two public methods to force-close a (single)
channel - `force_close_broadcasting_latest_txn` and
`force_close_without_broadcasting_txn`. The second exists to allow
a user who has restored a stale backup to (sort of) recover their
funds by starting, force-closing channels without broadcasting
their latest state, and only then reconnecting to peers (which
would otherwise cause a panic due to the stale state).
To my knowledge, no one has ever implemented this (fairly
half-assed) recovery flow, and more importantly its rather
substantially broken. `ChannelMonitor` has never tracked any
concept of whether a channel is stale, and if we connect blocks
towards an HTLC time-out it will immediately broadcast the stale
state anyway.
Finally, we really shouldn't encourage users to try to "recover"
from a stale state by running an otherwise-operational node on the
other end. Rather, we should formalize such a recovery flow by
having a `ChainMonitor` variant that takes a list of
`ChannelMonitor`s and claims available funds, dropping the
`ChannelManager` entirely.
While work continues towards that goal, having long-broken
functionality in `ChannelManager` is also not acceptable, so here
we simply remove the "without broadcasting" force-closure version.
Fixes#2875
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\
8332
8327
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\
8333
8328
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\
8334
-
If you have restored from an old backup and wish to force-close channels and return to operation, you should start up, call\n\
8335
-
ChannelManager::force_close_without_broadcasting_txn on channel {} with counterparty {} or\n\
8336
-
ChannelManager::force_close_all_channels_without_broadcasting_txn, then reconnect to peer(s).\n\
8337
-
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\
8338
-
See https://github.com/lightningdevkit/rust-lightning/issues/1565 for more info.");
8329
+
If you have restored from an old backup and wish to claim any available funds, you should restart with\n\
8330
+
an empty ChannelManager and no ChannelMonitors, reconnect to peer(s), ensure they've force-closed all of your\n\
8331
+
previous channels and that the closure transaction(s) have confirmed on-chain,\n\
8332
+
then restart with an empty ChannelManager and the latest ChannelMonitors that you do have.");
// N.B. that we don't send any channel close event here: we
4393
-
// don't have a user_channel_id, and we never sent any opening
4394
-
// events anyway.
4395
-
None
4396
-
} else {
4397
-
return Err(APIError::ChannelUnavailable{ err: format!("Channel with id {} not found for the passed counterparty node_id {}", channel_id, peer_node_id) });
4398
-
}
4370
+
let mut peer_state_lock = peer_state_mutex.lock().unwrap();
4371
+
let peer_state = &mut *peer_state_lock;
4372
+
let logger = WithContext::from(&self.logger, Some(*peer_node_id), Some(*channel_id), None);
4373
+
4374
+
let is_from_counterparty = matches!(reason, ClosureReason::CounterpartyForceClosed { .. });
0 commit comments