_ Git - ldk-java/blob - src/main/java/org/ldk/enums/ConfirmationTarget.java

   1 package org.ldk.enums;
   2
   3 /**
   4  * An enum that represents the priority at which we want a transaction to confirm used for feerate
   5  * estimation.
   6  */
   7 public enum ConfirmationTarget {
   8         /**
   9          * We have some funds available on chain which we need to spend prior to some expiry time at
  10          * which point our counterparty may be able to steal them. Generally we have in the high tens
  11          * to low hundreds of blocks to get our transaction on-chain, but we shouldn't risk too low a
  12          * fee - this should be a relatively high priority feerate.
  13          */
  14         LDKConfirmationTarget_OnChainSweep,
  15         /**
  16          * The highest feerate we will allow our channel counterparty to have in a non-anchor channel.
  17          *
  18          * This is the feerate on the transaction which we (or our counterparty) will broadcast in
  19          * order to close the channel unilaterally. Because our counterparty must ensure they can
  20          * always broadcast the latest state, this value being too low will cause immediate
  21          * force-closures.
  22          *
  23          * Allowing this value to be too high can allow our counterparty to burn our HTLC outputs to
  24          * dust, which can result in HTLCs failing or force-closures (when the dust HTLCs exceed
  25          * [`ChannelConfig::max_dust_htlc_exposure`]).
  26          *
  27          * Because most nodes use a feerate estimate which is based on a relatively high priority
  28          * transaction entering the current mempool, setting this to a small multiple of your current
  29          * high priority feerate estimate should suffice.
  30          *
  31          * [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
  32          */
  33         LDKConfirmationTarget_MaxAllowedNonAnchorChannelRemoteFee,
  34         /**
  35          * This is the lowest feerate we will allow our channel counterparty to have in an anchor
  36          * channel in order to close the channel if a channel party goes away.
  37          *
  38          * This needs to be sufficient to get into the mempool when the channel needs to
  39          * be force-closed. Setting too high may result in force-closures if our counterparty attempts
  40          * to use a lower feerate. Because this is for anchor channels, we can always bump the feerate
  41          * later; the feerate here only needs to be sufficient to enter the mempool.
  42          *
  43          * A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
  44          * is not an estimate which is very easy to calculate because we do not know the future. Using
  45          * a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
  46          * ensure you can always close the channel. A future change to Bitcoin's P2P network
  47          * (package relay) may obviate the need for this entirely.
  48          */
  49         LDKConfirmationTarget_MinAllowedAnchorChannelRemoteFee,
  50         /**
  51          * The lowest feerate we will allow our channel counterparty to have in a non-anchor channel.
  52          *
  53          * This is the feerate on the transaction which we (or our counterparty) will broadcast in
  54          * order to close the channel if a channel party goes away. Setting this value too high will
  55          * cause immediate force-closures in order to avoid having an unbroadcastable state.
  56          *
  57          * This feerate represents the fee we pick now, which must be sufficient to enter a block at an
  58          * arbitrary time in the future. Obviously this is not an estimate which is very easy to
  59          * calculate. This can leave channels subject to being unable to close if feerates rise, and in
  60          * general you should prefer anchor channels to ensure you can increase the feerate when the
  61          * transactions need broadcasting.
  62          *
  63          * Do note some fee estimators round up to the next full sat/vbyte (ie 250 sats per kw),
  64          * causing occasional issues with feerate disagreements between an initiator that wants a
  65          * feerate of 1.1 sat/vbyte and a receiver that wants 1.1 rounded up to 2. If your fee
  66          * estimator rounds subtracting 250 to your desired feerate here can help avoid this issue.
  67          *
  68          * [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
  69          */
  70         LDKConfirmationTarget_MinAllowedNonAnchorChannelRemoteFee,
  71         /**
  72          * This is the feerate on the transaction which we (or our counterparty) will broadcast in
  73          * order to close the channel if a channel party goes away.
  74          *
  75          * This needs to be sufficient to get into the mempool when the channel needs to
  76          * be force-closed. Setting too low may result in force-closures. Because this is for anchor
  77          * channels, it can be a low value as we can always bump the feerate later.
  78          *
  79          * A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
  80          * is not an estimate which is very easy to calculate because we do not know the future. Using
  81          * a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
  82          * ensure you can always close the channel. A future change to Bitcoin's P2P network
  83          * (package relay) may obviate the need for this entirely.
  84          */
  85         LDKConfirmationTarget_AnchorChannelFee,
  86         /**
  87          * Lightning is built around the ability to broadcast a transaction in the future to close our
  88          * channel and claim all pending funds. In order to do so, non-anchor channels are built with
  89          * transactions which we need to be able to broadcast at some point in the future.
  90          *
  91          * This feerate represents the fee we pick now, which must be sufficient to enter a block at an
  92          * arbitrary time in the future. Obviously this is not an estimate which is very easy to
  93          * calculate, so most lightning nodes use some relatively high-priority feerate using the
  94          * current mempool. This leaves channels subject to being unable to close if feerates rise, and
  95          * in general you should prefer anchor channels to ensure you can increase the feerate when the
  96          * transactions need broadcasting.
  97          *
  98          * Since this should represent the feerate of a channel close that does not need fee
  99          * bumping, this is also used as an upper bound for our attempted feerate when doing cooperative
 100          * closure of any channel.
 101          */
 102         LDKConfirmationTarget_NonAnchorChannelFee,
 103         /**
 104          * When cooperatively closing a channel, this is the minimum feerate we will accept.
 105          * Recommended at least within a day or so worth of blocks.
 106          *
 107          * This will also be used when initiating a cooperative close of a channel. When closing a
 108          * channel you can override this fee by using
 109          * [`ChannelManager::close_channel_with_feerate_and_script`].
 110          *
 111          * [`ChannelManager::close_channel_with_feerate_and_script`]: crate::ln::channelmanager::ChannelManager::close_channel_with_feerate_and_script
 112          */
 113         LDKConfirmationTarget_ChannelCloseMinimum,
 114         ; static native void init();
 115         static { init(); }
 116 }