4 * An enum that represents the priority at which we want a transaction to confirm used for feerate
7 public enum ConfirmationTarget {
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.
14 LDKConfirmationTarget_OnChainSweep,
16 * This is the lowest feerate we will allow our channel counterparty to have in an anchor
17 * channel in order to close the channel if a channel party goes away.
19 * This needs to be sufficient to get into the mempool when the channel needs to
20 * be force-closed. Setting too high may result in force-closures if our counterparty attempts
21 * to use a lower feerate. Because this is for anchor channels, we can always bump the feerate
22 * later; the feerate here only needs to be sufficient to enter the mempool.
24 * A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
25 * is not an estimate which is very easy to calculate because we do not know the future. Using
26 * a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
27 * ensure you can always close the channel. A future change to Bitcoin's P2P network
28 * (package relay) may obviate the need for this entirely.
30 LDKConfirmationTarget_MinAllowedAnchorChannelRemoteFee,
32 * The lowest feerate we will allow our channel counterparty to have in a non-anchor channel.
34 * This is the feerate on the transaction which we (or our counterparty) will broadcast in
35 * order to close the channel if a channel party goes away. Setting this value too high will
36 * cause immediate force-closures in order to avoid having an unbroadcastable state.
38 * This feerate represents the fee we pick now, which must be sufficient to enter a block at an
39 * arbitrary time in the future. Obviously this is not an estimate which is very easy to
40 * calculate. This can leave channels subject to being unable to close if feerates rise, and in
41 * general you should prefer anchor channels to ensure you can increase the feerate when the
42 * transactions need broadcasting.
44 * Do note some fee estimators round up to the next full sat/vbyte (ie 250 sats per kw),
45 * causing occasional issues with feerate disagreements between an initiator that wants a
46 * feerate of 1.1 sat/vbyte and a receiver that wants 1.1 rounded up to 2. If your fee
47 * estimator rounds subtracting 250 to your desired feerate here can help avoid this issue.
49 * [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
51 LDKConfirmationTarget_MinAllowedNonAnchorChannelRemoteFee,
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.
56 * This needs to be sufficient to get into the mempool when the channel needs to
57 * be force-closed. Setting too low may result in force-closures. Because this is for anchor
58 * channels, it can be a low value as we can always bump the feerate later.
60 * A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
61 * is not an estimate which is very easy to calculate because we do not know the future. Using
62 * a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
63 * ensure you can always close the channel. A future change to Bitcoin's P2P network
64 * (package relay) may obviate the need for this entirely.
66 LDKConfirmationTarget_AnchorChannelFee,
68 * Lightning is built around the ability to broadcast a transaction in the future to close our
69 * channel and claim all pending funds. In order to do so, non-anchor channels are built with
70 * transactions which we need to be able to broadcast at some point in the future.
72 * This feerate represents the fee we pick now, which must be sufficient to enter a block at an
73 * arbitrary time in the future. Obviously this is not an estimate which is very easy to
74 * calculate, so most lightning nodes use some relatively high-priority feerate using the
75 * current mempool. This leaves channels subject to being unable to close if feerates rise, and
76 * in general you should prefer anchor channels to ensure you can increase the feerate when the
77 * transactions need broadcasting.
79 * Since this should represent the feerate of a channel close that does not need fee
80 * bumping, this is also used as an upper bound for our attempted feerate when doing cooperative
81 * closure of any channel.
83 LDKConfirmationTarget_NonAnchorChannelFee,
85 * When cooperatively closing a channel, this is the minimum feerate we will accept.
86 * Recommended at least within a day or so worth of blocks.
88 * This will also be used when initiating a cooperative close of a channel. When closing a
89 * channel you can override this fee by using
90 * [`ChannelManager::close_channel_with_feerate_and_script`].
92 * [`ChannelManager::close_channel_with_feerate_and_script`]: crate::ln::channelmanager::ChannelManager::close_channel_with_feerate_and_script
94 LDKConfirmationTarget_ChannelCloseMinimum,
95 ; static native void init();
96 static { org.ldk.impl.bindings.run_statics(); init(); }