X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=src%2Fmain%2Fjava%2Forg%2Fldk%2Fenums%2FConfirmationTarget.java;fp=src%2Fmain%2Fjava%2Forg%2Fldk%2Fenums%2FConfirmationTarget.java;h=4098a1231f3558ca62a8b369ea552d193dc3a8a7;hb=2bb592fb946e316dba9f4d1123f8ac72ff4e9bf8;hp=bca6ce552c3d6343075158f991712249d857da44;hpb=519dc944de5b88f95975140a13fbc6d77dd15a95;p=ldk-java

diff --git a/src/main/java/org/ldk/enums/ConfirmationTarget.java b/src/main/java/org/ldk/enums/ConfirmationTarget.java
index bca6ce55..4098a123 100644
--- a/src/main/java/org/ldk/enums/ConfirmationTarget.java
+++ b/src/main/java/org/ldk/enums/ConfirmationTarget.java
@@ -12,25 +12,6 @@ public enum ConfirmationTarget {
 	 * 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.
-	 * 
-	 * 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_MaxAllowedNonAnchorChannelRemoteFee,
 	/**
 	 * 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.