[Java] Update auto-generated bindings to LDK 0.0.118

Author: TheBlueMatt

src/main/java/org/ldk/enums/Bolt12SemanticError.java

@@ -88,6 +88,10 @@ public enum Bolt12SemanticError {
 	 * A payer id was expected but was missing.
 	 */
 	LDKBolt12SemanticError_MissingPayerId,
+	/**
+	 * The payment id for a refund or request is already in use.
+	 */
+	LDKBolt12SemanticError_DuplicatePaymentId,
 	/**
 	 * Blinded paths were expected but were missing.
 	 */

src/main/java/org/ldk/enums/ConfirmationTarget.java

@@ -6,28 +6,111 @@
  */
 public enum ConfirmationTarget {
 	/**
-	 * We'd like a transaction to confirm in the future, but don't want to commit most of the fees
-	 * required to do so yet. The remaining fees will come via a Child-Pays-For-Parent (CPFP) fee
-	 * bump of the transaction.
+	 * We have some funds available on chain which we need to spend prior to some expiry time at
+	 * which point our counterparty may be able to steal them. Generally we have in the high tens
+	 * to low hundreds of blocks to get our transaction on-chain, but we shouldn't risk too low a
+	 * fee - this should be a relatively high priority feerate.
+	 */
+	LDKConfirmationTarget_OnChainSweep,
+	/**
+	 * The highest feerate we will allow our channel counterparty to have in a non-anchor channel.
+	 * 
+	 * This is the feerate on the transaction which we (or our counterparty) will broadcast in
+	 * order to close the channel unilaterally. Because our counterparty must ensure they can
+	 * always broadcast the latest state, this value being too low will cause immediate
+	 * force-closures.
 	 * 
-	 * The feerate returned should be the absolute minimum feerate required to enter most node
-	 * mempools across the network. Note that if you are not able to obtain this feerate estimate,
-	 * you should likely use the furthest-out estimate allowed by your fee estimator.
+	 * Allowing this value to be too high can allow our counterparty to burn our HTLC outputs to
+	 * dust, which can result in HTLCs failing or force-closures (when the dust HTLCs exceed
+	 * [`ChannelConfig::max_dust_htlc_exposure`]).
+	 * 
+	 * Because most nodes use a feerate estimate which is based on a relatively high priority
+	 * transaction entering the current mempool, setting this to a small multiple of your current
+	 * high priority feerate estimate should suffice.
+	 * 
+	 * [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
 	 */
-	LDKConfirmationTarget_MempoolMinimum,
+	LDKConfirmationTarget_MaxAllowedNonAnchorChannelRemoteFee,
 	/**
-	 * We are happy with a transaction confirming slowly, at least within a day or so worth of
-	 * blocks.
+	 * This is the lowest feerate we will allow our channel counterparty to have in an anchor
+	 * channel in order to close the channel if a channel party goes away.
+	 * 
+	 * This needs to be sufficient to get into the mempool when the channel needs to
+	 * be force-closed. Setting too high may result in force-closures if our counterparty attempts
+	 * to use a lower feerate. Because this is for anchor channels, we can always bump the feerate
+	 * later; the feerate here only needs to be sufficient to enter the mempool.
+	 * 
+	 * A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
+	 * is not an estimate which is very easy to calculate because we do not know the future. Using
+	 * a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
+	 * ensure you can always close the channel. A future change to Bitcoin's P2P network
+	 * (package relay) may obviate the need for this entirely.
 	 */
-	LDKConfirmationTarget_Background,
+	LDKConfirmationTarget_MinAllowedAnchorChannelRemoteFee,
 	/**
-	 * We'd like a transaction to confirm without major delayed, i.e., within the next 12-24 blocks.
+	 * The lowest feerate we will allow our channel counterparty to have in a non-anchor channel.
+	 * 
+	 * This is the feerate on the transaction which we (or our counterparty) will broadcast in
+	 * order to close the channel if a channel party goes away. Setting this value too high will
+	 * cause immediate force-closures in order to avoid having an unbroadcastable state.
+	 * 
+	 * This feerate represents the fee we pick now, which must be sufficient to enter a block at an
+	 * arbitrary time in the future. Obviously this is not an estimate which is very easy to
+	 * calculate. This can leave channels subject to being unable to close if feerates rise, and in
+	 * general you should prefer anchor channels to ensure you can increase the feerate when the
+	 * transactions need broadcasting.
+	 * 
+	 * Do note some fee estimators round up to the next full sat/vbyte (ie 250 sats per kw),
+	 * causing occasional issues with feerate disagreements between an initiator that wants a
+	 * feerate of 1.1 sat/vbyte and a receiver that wants 1.1 rounded up to 2. If your fee
+	 * estimator rounds subtracting 250 to your desired feerate here can help avoid this issue.
+	 * 
+	 * [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
 	 */
-	LDKConfirmationTarget_Normal,
+	LDKConfirmationTarget_MinAllowedNonAnchorChannelRemoteFee,
 	/**
-	 * We'd like a transaction to confirm in the next few blocks.
+	 * This is the feerate on the transaction which we (or our counterparty) will broadcast in
+	 * order to close the channel if a channel party goes away.
+	 * 
+	 * This needs to be sufficient to get into the mempool when the channel needs to
+	 * be force-closed. Setting too low may result in force-closures. Because this is for anchor
+	 * channels, it can be a low value as we can always bump the feerate later.
+	 * 
+	 * A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
+	 * is not an estimate which is very easy to calculate because we do not know the future. Using
+	 * a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
+	 * ensure you can always close the channel. A future change to Bitcoin's P2P network
+	 * (package relay) may obviate the need for this entirely.
+	 */
+	LDKConfirmationTarget_AnchorChannelFee,
+	/**
+	 * Lightning is built around the ability to broadcast a transaction in the future to close our
+	 * channel and claim all pending funds. In order to do so, non-anchor channels are built with
+	 * transactions which we need to be able to broadcast at some point in the future.
+	 * 
+	 * This feerate represents the fee we pick now, which must be sufficient to enter a block at an
+	 * arbitrary time in the future. Obviously this is not an estimate which is very easy to
+	 * calculate, so most lightning nodes use some relatively high-priority feerate using the
+	 * current mempool. This leaves channels subject to being unable to close if feerates rise, and
+	 * in general you should prefer anchor channels to ensure you can increase the feerate when the
+	 * transactions need broadcasting.
+	 * 
+	 * Since this should represent the feerate of a channel close that does not need fee
+	 * bumping, this is also used as an upper bound for our attempted feerate when doing cooperative
+	 * closure of any channel.
+	 */
+	LDKConfirmationTarget_NonAnchorChannelFee,
+	/**
+	 * When cooperatively closing a channel, this is the minimum feerate we will accept.
+	 * Recommended at least within a day or so worth of blocks.
+	 * 
+	 * This will also be used when initiating a cooperative close of a channel. When closing a
+	 * channel you can override this fee by using
+	 * [`ChannelManager::close_channel_with_feerate_and_script`].
+	 * 
+	 * [`ChannelManager::close_channel_with_feerate_and_script`]: crate::ln::channelmanager::ChannelManager::close_channel_with_feerate_and_script
 	 */
-	LDKConfirmationTarget_HighPriority,
+	LDKConfirmationTarget_ChannelCloseMinimum,
 	; static native void init();
 	static { init(); }
 }