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