Trait lightning::chain::channelmonitor::Persist[][src]

pub trait Persist<ChannelSigner: Sign> {
    fn persist_new_channel(
        &self,
        id: OutPoint,
        data: &ChannelMonitor<ChannelSigner>
    ) -> Result<(), ChannelMonitorUpdateErr>;
fn update_persisted_channel(
        &self,
        id: OutPoint,
        update: &ChannelMonitorUpdate,
        data: &ChannelMonitor<ChannelSigner>
    ) -> Result<(), ChannelMonitorUpdateErr>; }

Persist defines behavior for persisting channel monitors: this could mean writing once to disk, and/or uploading to one or more backup services.

Note that for every new monitor, you must persist the new ChannelMonitor to disk/backups. And, on every update, you must persist either the ChannelMonitorUpdate or the updated monitor itself. Otherwise, there is risk of situations such as revoking a transaction, then crashing before this revocation can be persisted, then unintentionally broadcasting a revoked transaction and losing money. This is a risk because previous channel states are toxic, so it’s important that whatever channel state is persisted is kept up-to-date.

Required methods

fn persist_new_channel(
    &self,
    id: OutPoint,
    data: &ChannelMonitor<ChannelSigner>
) -> Result<(), ChannelMonitorUpdateErr>
[src]

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.

fn update_persisted_channel(
    &self,
    id: OutPoint,
    update: &ChannelMonitorUpdate,
    data: &ChannelMonitor<ChannelSigner>
) -> Result<(), ChannelMonitorUpdateErr>
[src]

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.

Loading content...

Implementors

Loading content...