_ Git - ldk-java/blob - src/main/java/org/ldk/structs/Persist.java

   1 package org.ldk.structs;
   2
   3 import org.ldk.impl.bindings;
   4 import org.ldk.enums.*;
   5 import org.ldk.util.*;
   6 import java.util.Arrays;
   7 import javax.annotation.Nullable;
   8
   9 /**
  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.
  12  *
  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
  20  * kept up-to-date.
  21  */
  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;
  30         }
  31         @Override @SuppressWarnings("deprecation")
  32         protected void finalize() throws Throwable {
  33                 if (ptr != 0) { bindings.Persist_free(ptr); } super.finalize();
  34         }
  35
  36         public static interface PersistInterface {
  37                 /**
  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.
  43                  *
  44                  * See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`,
  45                  * and [`ChannelMonitorUpdateErr`] for requirements when returning errors.
  46                  */
  47                 Result_NoneChannelMonitorUpdateErrZ persist_new_channel(OutPoint id, ChannelMonitor data);
  48                 /**
  49                  * Update one channel's data. The provided `ChannelMonitor` has already
  50                  * applied the given update.
  51                  *
  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.
  55                  *
  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.
  62                  *
  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)`.
  67                  *
  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.
  71                  */
  72                 Result_NoneChannelMonitorUpdateErrZ update_persisted_channel(OutPoint id, ChannelMonitorUpdate update, ChannelMonitor data);
  73         }
  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;
  84                                 return result;
  85                         }
  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;
  93                                 return result;
  94                         }
  95                 });
  96                 return impl_holder.held;
  97         }
  98         /**
  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.
 104          *
 105          * See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`,
 106          * and [`ChannelMonitorUpdateErr`] for requirements when returning errors.
 107          */
 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);
 114                 return ret_hu_conv;
 115         }
 116
 117         /**
 118          * Update one channel's data. The provided `ChannelMonitor` has already
 119          * applied the given update.
 120          *
 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.
 124          *
 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.
 131          *
 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)`.
 136          *
 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.
 140          */
 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);
 148                 return ret_hu_conv;
 149         }
 150
 151 }