Package org.ldk.structs
Interface Persist.PersistInterface
-
- Enclosing class:
- Persist
public static interface Persist.PersistInterface
-
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description Result_NoneChannelMonitorUpdateErrZ
persist_new_channel(OutPoint id, ChannelMonitor data)
Persist a new channel's data.Result_NoneChannelMonitorUpdateErrZ
update_persisted_channel(OutPoint id, ChannelMonitorUpdate update, ChannelMonitor data)
Update one channel's data.
-
-
-
Method Detail
-
persist_new_channel
Result_NoneChannelMonitorUpdateErrZ persist_new_channel(OutPoint id, ChannelMonitor data)
Persist a new channel's data. The data can be stored any way you want, but the identifier provided by Rust-Lightning is the channel's outpoint (and it is up to you to maintain a correct mapping between the outpoint and the stored channel data). Note that you **must** persist every new monitor to disk. See the `Persist` trait documentation for more details. See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`, and [`ChannelMonitorUpdateErr`] for requirements when returning errors.
-
update_persisted_channel
Result_NoneChannelMonitorUpdateErrZ update_persisted_channel(OutPoint id, ChannelMonitorUpdate update, ChannelMonitor data)
Update one channel's data. The provided `ChannelMonitor` has already applied the given update. Note that on every update, you **must** persist either the `ChannelMonitorUpdate` or the updated monitor itself to disk/backups. See the `Persist` trait documentation for more details. If an implementer chooses to persist the updates only, they need to make sure that all the updates are applied to the `ChannelMonitors` *before the set of channel monitors is given to the `ChannelManager` deserialization routine. See [`ChannelMonitor::update_monitor`] for applying a monitor update to a monitor. If full `ChannelMonitors` are persisted, then there is no need to persist individual updates. Note that there could be a performance tradeoff between persisting complete channel monitors on every update vs. persisting only updates and applying them in batches. The size of each monitor grows `O(number of state updates)` whereas updates are small and `O(1)`. See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`, [`ChannelMonitorUpdate::write`] for writing out an update, and [`ChannelMonitorUpdateErr`] for requirements when returning errors.
-
-