X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=lightning%2Fsrc%2Fchain%2Fchaininterface.rs;h=1f42dc2fe4251a26be3c7b659bae89505893b6e3;hb=refs%2Fheads%2F2024-04-log-in-flights;hp=dfb90135c88de84b2d9fe962c9e05d354cbab86b;hpb=be8797e17ab5c56582340d1f5e57f92477ede69d;p=rust-lightning

diff --git a/lightning/src/chain/chaininterface.rs b/lightning/src/chain/chaininterface.rs
index dfb90135..1f42dc2f 100644
--- a/lightning/src/chain/chaininterface.rs
+++ b/lightning/src/chain/chaininterface.rs
@@ -40,7 +40,7 @@ pub trait BroadcasterInterface {
 	/// be sure to manage both cases correctly.
 	///
 	/// Bitcoin transaction packages are defined in BIP 331 and here:
-	/// https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md
+	/// <https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md>
 	fn broadcast_transactions(&self, txs: &[&Transaction]);
 }
 
@@ -53,32 +53,13 @@ pub enum ConfirmationTarget {
 	/// 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.
 	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
-	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. Because our counterparty
-	/// must ensure they can always broadcast the latest state, this value being too high will cause
-	/// immediate force-closures.
+	/// 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 low may result in force-closures. Because this is for anchor
-	/// channels, we can always bump the feerate later, the feerate here only needs to suffice to
-	/// enter the mempool.
+	/// 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
@@ -87,13 +68,10 @@ pub enum ConfirmationTarget {
 	/// (package relay) may obviate the need for this entirely.
 	MinAllowedAnchorChannelRemoteFee,
 	/// The lowest feerate we will allow our channel counterparty to have in a non-anchor channel.
-	/// This needs to be sufficient to get confirmed when the channel needs to be force-closed.
-	/// Setting too low may result in force-closures.
 	///
 	/// 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. Because our counterparty must
-	/// ensure they can always broadcast the latest state, this value being too high will cause
-	/// immediate force-closures.
+	/// 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