1 package org.ldk.structs;
3 import org.ldk.impl.bindings;
4 import org.ldk.enums.*;
6 import java.util.Arrays;
7 import javax.annotation.Nullable;
10 * `Persist` defines behavior for persisting channel monitors: this could mean
11 * writing once to disk, and/or uploading to one or more backup services.
13 * Note that for every new monitor, you **must** persist the new `ChannelMonitor`
14 * to disk/backups. And, on every update, you **must** persist either the
15 * `ChannelMonitorUpdate` or the updated monitor itself. Otherwise, there is risk
16 * of situations such as revoking a transaction, then crashing before this
17 * revocation can be persisted, then unintentionally broadcasting a revoked
18 * transaction and losing money. This is a risk because previous channel states
19 * are toxic, so it's important that whatever channel state is persisted is
22 @SuppressWarnings("unchecked") // We correctly assign various generic arrays
23 public class Persist extends CommonBase {
24 final bindings.LDKPersist bindings_instance;
25 Persist(Object _dummy, long ptr) { super(ptr); bindings_instance = null; }
26 private Persist(bindings.LDKPersist arg) {
27 super(bindings.LDKPersist_new(arg));
28 this.ptrs_to.add(arg);
29 this.bindings_instance = arg;
31 @Override @SuppressWarnings("deprecation")
32 protected void finalize() throws Throwable {
33 if (ptr != 0) { bindings.Persist_free(ptr); } super.finalize();
36 public static interface PersistInterface {
38 * Persist a new channel's data. The data can be stored any way you want, but
39 * the identifier provided by Rust-Lightning is the channel's outpoint (and
40 * it is up to you to maintain a correct mapping between the outpoint and the
41 * stored channel data). Note that you **must** persist every new monitor to
42 * disk. See the `Persist` trait documentation for more details.
44 * See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`,
45 * and [`ChannelMonitorUpdateErr`] for requirements when returning errors.
47 Result_NoneChannelMonitorUpdateErrZ persist_new_channel(OutPoint id, ChannelMonitor data);
49 * Update one channel's data. The provided `ChannelMonitor` has already
50 * applied the given update.
52 * Note that on every update, you **must** persist either the
53 * `ChannelMonitorUpdate` or the updated monitor itself to disk/backups. See
54 * the `Persist` trait documentation for more details.
56 * If an implementer chooses to persist the updates only, they need to make
57 * sure that all the updates are applied to the `ChannelMonitors` *before
58 * the set of channel monitors is given to the `ChannelManager`
59 * deserialization routine. See [`ChannelMonitor::update_monitor`] for
60 * applying a monitor update to a monitor. If full `ChannelMonitors` are
61 * persisted, then there is no need to persist individual updates.
63 * Note that there could be a performance tradeoff between persisting complete
64 * channel monitors on every update vs. persisting only updates and applying
65 * them in batches. The size of each monitor grows `O(number of state updates)`
66 * whereas updates are small and `O(1)`.
68 * See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`,
69 * [`ChannelMonitorUpdate::write`] for writing out an update, and
70 * [`ChannelMonitorUpdateErr`] for requirements when returning errors.
72 Result_NoneChannelMonitorUpdateErrZ update_persisted_channel(OutPoint id, ChannelMonitorUpdate update, ChannelMonitor data);
74 private static class LDKPersistHolder { Persist held; }
75 public static Persist new_impl(PersistInterface arg) {
76 final LDKPersistHolder impl_holder = new LDKPersistHolder();
77 impl_holder.held = new Persist(new bindings.LDKPersist() {
78 @Override public long persist_new_channel(long id, long data) {
79 OutPoint id_hu_conv = new OutPoint(null, id);
80 id_hu_conv.ptrs_to.add(this);
81 ChannelMonitor data_hu_conv = new ChannelMonitor(null, data);
82 Result_NoneChannelMonitorUpdateErrZ ret = arg.persist_new_channel(id_hu_conv, data_hu_conv);
83 long result = ret != null ? ret.ptr : 0;
86 @Override public long update_persisted_channel(long id, long update, long data) {
87 OutPoint id_hu_conv = new OutPoint(null, id);
88 id_hu_conv.ptrs_to.add(this);
89 ChannelMonitorUpdate update_hu_conv = new ChannelMonitorUpdate(null, update);
90 ChannelMonitor data_hu_conv = new ChannelMonitor(null, data);
91 Result_NoneChannelMonitorUpdateErrZ ret = arg.update_persisted_channel(id_hu_conv, update_hu_conv, data_hu_conv);
92 long result = ret != null ? ret.ptr : 0;
96 return impl_holder.held;
99 * Persist a new channel's data. The data can be stored any way you want, but
100 * the identifier provided by Rust-Lightning is the channel's outpoint (and
101 * it is up to you to maintain a correct mapping between the outpoint and the
102 * stored channel data). Note that you **must** persist every new monitor to
103 * disk. See the `Persist` trait documentation for more details.
105 * See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`,
106 * and [`ChannelMonitorUpdateErr`] for requirements when returning errors.
108 public Result_NoneChannelMonitorUpdateErrZ persist_new_channel(OutPoint id, ChannelMonitor data) {
109 long ret = bindings.Persist_persist_new_channel(this.ptr, id == null ? 0 : id.ptr & ~1, data == null ? 0 : data.ptr & ~1);
110 if (ret < 1024) { return null; }
111 Result_NoneChannelMonitorUpdateErrZ ret_hu_conv = Result_NoneChannelMonitorUpdateErrZ.constr_from_ptr(ret);
112 this.ptrs_to.add(id);
113 this.ptrs_to.add(data);
118 * Update one channel's data. The provided `ChannelMonitor` has already
119 * applied the given update.
121 * Note that on every update, you **must** persist either the
122 * `ChannelMonitorUpdate` or the updated monitor itself to disk/backups. See
123 * the `Persist` trait documentation for more details.
125 * If an implementer chooses to persist the updates only, they need to make
126 * sure that all the updates are applied to the `ChannelMonitors` *before
127 * the set of channel monitors is given to the `ChannelManager`
128 * deserialization routine. See [`ChannelMonitor::update_monitor`] for
129 * applying a monitor update to a monitor. If full `ChannelMonitors` are
130 * persisted, then there is no need to persist individual updates.
132 * Note that there could be a performance tradeoff between persisting complete
133 * channel monitors on every update vs. persisting only updates and applying
134 * them in batches. The size of each monitor grows `O(number of state updates)`
135 * whereas updates are small and `O(1)`.
137 * See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`,
138 * [`ChannelMonitorUpdate::write`] for writing out an update, and
139 * [`ChannelMonitorUpdateErr`] for requirements when returning errors.
141 public Result_NoneChannelMonitorUpdateErrZ update_persisted_channel(OutPoint id, ChannelMonitorUpdate update, ChannelMonitor data) {
142 long ret = bindings.Persist_update_persisted_channel(this.ptr, id == null ? 0 : id.ptr & ~1, update == null ? 0 : update.ptr & ~1, data == null ? 0 : data.ptr & ~1);
143 if (ret < 1024) { return null; }
144 Result_NoneChannelMonitorUpdateErrZ ret_hu_conv = Result_NoneChannelMonitorUpdateErrZ.constr_from_ptr(ret);
145 this.ptrs_to.add(id);
146 this.ptrs_to.add(update);
147 this.ptrs_to.add(data);