Merge pull request #2307 from benthecarman/verify-funcs
[rust-lightning] / lightning / src / chain / chainmonitor.rs
index 261e5593b5b4600ad661142a4579308b68903316..562c76fa3e2c996f136c54d8fb4adb36baeba802 100644 (file)
@@ -502,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<events::Event> {
                use crate::events::EventsProvider;
                let events = core::cell::RefCell::new(Vec::new());
@@ -782,30 +782,13 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
              L::Target: Logger,
              P::Target: Persist<ChannelSigner>,
 {
-       #[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<H: Deref>(&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.