21
21
22
22
For those moving to the new ` ConfirmationTarget ` , the new variants in terms of
23
23
the old mempool/low/medium/high priorities are as follows:
24
- * OnChainSweep = HighPriority
25
- * MaxAllowedNonAnchorChannelRemoteFee = max(25 * 250, HighPriority * 10)
26
- * MinAllowedAnchorChannelRemoteFee = MempoolMinimum
27
- * MinAllowedNonAnchorChannelRemoteFee = Background - 250
28
- * AnchorChannelFee = Background
29
- * NonAnchorChannelFee = Normal
30
- * ChannelCloseMinimum = Background
24
+ * ` OnChainSweep ` = ` HighPriority `
25
+ * ` MaxAllowedNonAnchorChannelRemoteFee ` = ` max(25 * 250, HighPriority * 10) `
26
+ * ` MinAllowedAnchorChannelRemoteFee ` = ` MempoolMinimum `
27
+ * ` MinAllowedNonAnchorChannelRemoteFee ` = ` Background - 250 `
28
+ * ` AnchorChannelFee ` = ` Background `
29
+ * ` NonAnchorChannelFee ` = ` Normal `
30
+ * ` ChannelCloseMinimum ` = ` Background `
31
31
32
32
## Bug Fixes
33
33
* Calling ` ChannelManager::close_channel[_with_feerate_and_script] ` on a
@@ -41,7 +41,7 @@ the old mempool/low/medium/high priorities are as follows:
41
41
* Anchor outputs are now properly considered when calculating the amount
42
42
available to send in HTLCs. This can prevent force-closes in anchor channels
43
43
when sending payments which overflow the available balance (#2674 ).
44
- * A peer which sends an ` update_fulfill_htlc ` message for a forwarded HTLC,
44
+ * A peer that sends an ` update_fulfill_htlc ` message for a forwarded HTLC,
45
45
then reconnects prior to sending a ` commitment_signed ` (thus retransmitting
46
46
their ` update_fulfill_htlc ` ) may result in the channel stalling and being
47
47
unable to make progress (#2661 ).
0 commit comments