X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=lightning%2Fsrc%2Fchain%2Fchainmonitor.rs;h=562c76fa3e2c996f136c54d8fb4adb36baeba802;hb=a358ba2e68c84d19e70d1d45d3f677eaf324e09d;hp=f4109ac173d2e1cca2ec068a8271cd266f7b0593;hpb=09f5e50ed2c3ad4324a659d7c332815e03d97bda;p=rust-lightning diff --git a/lightning/src/chain/chainmonitor.rs b/lightning/src/chain/chainmonitor.rs index f4109ac1..562c76fa 100644 --- a/lightning/src/chain/chainmonitor.rs +++ b/lightning/src/chain/chainmonitor.rs @@ -31,7 +31,7 @@ use crate::chain::{ChannelMonitorUpdateStatus, Filter, WatchedOutput}; use crate::chain::chaininterface::{BroadcasterInterface, FeeEstimator}; use crate::chain::channelmonitor::{ChannelMonitor, ChannelMonitorUpdate, Balance, MonitorEvent, TransactionOutputs, LATENCY_GRACE_PERIOD_BLOCKS}; use crate::chain::transaction::{OutPoint, TransactionData}; -use crate::chain::keysinterface::WriteableEcdsaChannelSigner; +use crate::sign::WriteableEcdsaChannelSigner; use crate::events; use crate::events::{Event, EventHandler}; use crate::util::atomic_counter::AtomicCounter; @@ -217,8 +217,15 @@ impl Deref for LockedChannelMonitor< /// or used independently to monitor channels remotely. See the [module-level documentation] for /// details. /// +/// Note that `ChainMonitor` should regularly trigger rebroadcasts/fee bumps of pending claims from +/// a force-closed channel. This is crucial in preventing certain classes of pinning attacks, +/// detecting substantial mempool feerate changes between blocks, and ensuring reliability if +/// broadcasting fails. We recommend invoking this every 30 seconds, or lower if running in an +/// environment with spotty connections, like on mobile. +/// /// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager /// [module-level documentation]: crate::chain::chainmonitor +/// [`rebroadcast_pending_claims`]: Self::rebroadcast_pending_claims pub struct ChainMonitor where C::Target: chain::Filter, T::Target: BroadcasterInterface, @@ -495,7 +502,7 @@ where C::Target: chain::Filter, self.event_notifier.notify(); } - #[cfg(any(test, fuzzing, feature = "_test_utils"))] + #[cfg(any(test, feature = "_test_utils"))] pub fn get_and_clear_pending_events(&self) -> Vec { use crate::events::EventsProvider; let events = core::cell::RefCell::new(Vec::new()); @@ -533,6 +540,20 @@ where C::Target: chain::Filter, pub fn get_update_future(&self) -> Future { self.event_notifier.get_future() } + + /// Triggers rebroadcasts/fee-bumps of pending claims from a force-closed channel. This is + /// crucial in preventing certain classes of pinning attacks, detecting substantial mempool + /// feerate changes between blocks, and ensuring reliability if broadcasting fails. We recommend + /// invoking this every 30 seconds, or lower if running in an environment with spotty + /// connections, like on mobile. + pub fn rebroadcast_pending_claims(&self) { + let monitors = self.monitors.read().unwrap(); + for (_, monitor_holder) in &*monitors { + monitor_holder.monitor.rebroadcast_pending_claims( + &*self.broadcaster, &*self.fee_estimator, &*self.logger + ) + } + } } impl @@ -761,30 +782,13 @@ impl, { - #[cfg(not(anchors))] - /// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity. - /// - /// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in - /// order to handle these events. - /// - /// [`SpendableOutputs`]: events::Event::SpendableOutputs - fn process_pending_events(&self, handler: H) where H::Target: EventHandler { - let mut pending_events = Vec::new(); - for monitor_state in self.monitors.read().unwrap().values() { - pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events()); - } - for event in pending_events { - handler.handle_event(event); - } - } - #[cfg(anchors)] /// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity. /// /// For channels featuring anchor outputs, this method will also process [`BumpTransaction`] /// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain /// within each channel. As the confirmation of a commitment transaction may be critical to the - /// safety of funds, this method must be invoked frequently, ideally once for every chain tip - /// update (block connected or disconnected). + /// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an + /// environment with spotty connections, like on mobile. /// /// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in /// order to handle these events. @@ -804,15 +808,13 @@ impl