Enum breez_sdk_liquid::lightning::chain::chaininterface::ConfirmationTarget

pub enum ConfirmationTarget {
    OnChainSweep,
    MaxAllowedNonAnchorChannelRemoteFee,
    MinAllowedAnchorChannelRemoteFee,
    MinAllowedNonAnchorChannelRemoteFee,
    AnchorChannelFee,
    NonAnchorChannelFee,
    ChannelCloseMinimum,
}

An enum that represents the priority at which we want a transaction to confirm used for feerate estimation.

Variants

OnChainSweep

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.

MaxAllowedNonAnchorChannelRemoteFee

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.

MinAllowedAnchorChannelRemoteFee

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.

MinAllowedNonAnchorChannelRemoteFee

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.

AnchorChannelFee

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.

NonAnchorChannelFee

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.

ChannelCloseMinimum

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.

Trait Implementations

impl Clone for ConfirmationTarget

fn clone(&self) -> ConfirmationTarget

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ConfirmationTarget

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl Hash for ConfirmationTarget

fn hash<__H>(&self, state: &mut __H)

where __H: Hasher,

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H)

where H: Hasher, Self: Sized,

Feeds a slice of this type into the given Hasher.

impl PartialEq for ConfirmationTarget

fn eq(&self, other: &ConfirmationTarget) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Copy for ConfirmationTarget

impl Eq for ConfirmationTarget

impl StructuralPartialEq for ConfirmationTarget