_ Git - ldk-java/blob - src/main/java/org/ldk/enums/ChannelMonitorUpdateErr.java

   1 package org.ldk.enums;
   2
   3 /**
   4  * An error enum representing a failure to persist a channel monitor update.
   5  */
   6 public enum ChannelMonitorUpdateErr {
   7         /**
   8          * Used to indicate a temporary failure (eg connection to a watchtower or remote backup of
   9          * our state failed, but is expected to succeed at some point in the future).
  10          *
  11          * Such a failure will \"freeze\" a channel, preventing us from revoking old states or
  12          * submitting new commitment transactions to the counterparty. Once the update(s) that failed
  13          * have been successfully applied, a [`MonitorEvent::UpdateCompleted`] event should be returned
  14          * via [`Watch::release_pending_monitor_events`] which will then restore the channel to an
  15          * operational state.
  16          *
  17          * Note that a given ChannelManager will *never* re-generate a given ChannelMonitorUpdate. If
  18          * you return a TemporaryFailure you must ensure that it is written to disk safely before
  19          * writing out the latest ChannelManager state.
  20          *
  21          * Even when a channel has been \"frozen\" updates to the ChannelMonitor can continue to occur
  22          * (eg if an inbound HTLC which we forwarded was claimed upstream resulting in us attempting
  23          * to claim it on this channel) and those updates must be applied wherever they can be. At
  24          * least one such updated ChannelMonitor must be persisted otherwise PermanentFailure should
  25          * be returned to get things on-chain ASAP using only the in-memory copy. Obviously updates to
  26          * the channel which would invalidate previous ChannelMonitors are not made when a channel has
  27          * been \"frozen\".
  28          *
  29          * Note that even if updates made after TemporaryFailure succeed you must still provide a
  30          * [`MonitorEvent::UpdateCompleted`] to ensure you have the latest monitor and re-enable
  31          * normal channel operation. Note that this is normally generated through a call to
  32          * [`ChainMonitor::channel_monitor_updated`].
  33          *
  34          * Note that the update being processed here will not be replayed for you when you return a
  35          * [`MonitorEvent::UpdateCompleted`] event via [`Watch::release_pending_monitor_events`], so
  36          * you must store the update itself on your own local disk prior to returning a
  37          * TemporaryFailure. You may, of course, employ a journaling approach, storing only the
  38          * ChannelMonitorUpdate on disk without updating the monitor itself, replaying the journal at
  39          * reload-time.
  40          *
  41          * For deployments where a copy of ChannelMonitors and other local state are backed up in a
  42          * remote location (with local copies persisted immediately), it is anticipated that all
  43          * updates will return TemporaryFailure until the remote copies could be updated.
  44          *
  45          * [`ChainMonitor::channel_monitor_updated`]: chainmonitor::ChainMonitor::channel_monitor_updated
  46          */
  47         LDKChannelMonitorUpdateErr_TemporaryFailure,
  48         /**
  49          * Used to indicate no further channel monitor updates will be allowed (eg we've moved on to a
  50          * different watchtower and cannot update with all watchtowers that were previously informed
  51          * of this channel).
  52          *
  53          * At reception of this error, ChannelManager will force-close the channel and return at
  54          * least a final ChannelMonitorUpdate::ChannelForceClosed which must be delivered to at
  55          * least one ChannelMonitor copy. Revocation secret MUST NOT be released and offchain channel
  56          * update must be rejected.
  57          *
  58          * This failure may also signal a failure to update the local persisted copy of one of
  59          * the channel monitor instance.
  60          *
  61          * Note that even when you fail a holder commitment transaction update, you must store the
  62          * update to ensure you can claim from it in case of a duplicate copy of this ChannelMonitor
  63          * broadcasts it (e.g distributed channel-monitor deployment)
  64          *
  65          * In case of distributed watchtowers deployment, the new version must be written to disk, as
  66          * state may have been stored but rejected due to a block forcing a commitment broadcast. This
  67          * storage is used to claim outputs of rejected state confirmed onchain by another watchtower,
  68          * lagging behind on block processing.
  69          */
  70         LDKChannelMonitorUpdateErr_PermanentFailure,
  71         ; static native void init();
  72         static { init(); }
  73 }