|
4 | 4 | * An error enum representing a failure to persist a channel monitor update. |
5 | 5 | */ |
6 | 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 | + */ |
7 | 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 | + */ |
8 | 70 | LDKChannelMonitorUpdateErr_PermanentFailure, |
9 | 71 | ; static native void init(); |
10 | 72 | static { init(); } |
|
0 commit comments