Struct lightning::util::config::ChannelHandshakeConfig

pub struct ChannelHandshakeConfig {
    pub minimum_depth: u32,
    pub our_to_self_delay: u16,
    pub our_htlc_minimum_msat: u64,
    pub max_inbound_htlc_value_in_flight_percent_of_channel: u8,
    pub negotiate_scid_privacy: bool,
    pub announced_channel: bool,
    pub commit_upfront_shutdown_pubkey: bool,
}

Configuration we set when applicable.

Default::default() provides sane defaults.

Fields

minimum_depth: u32

Confirmations we will wait for before considering the channel locked in. Applied only for inbound channels (see ChannelHandshakeLimits::max_minimum_depth for the equivalent limit applied to outbound channels).

A lower-bound of 1 is applied, requiring all channels to have a confirmed commitment transaction before operation. If you wish to accept channels with zero confirmations, see UserConfig::manually_accept_inbound_channels and ChannelManager::accept_inbound_channel_from_trusted_peer_0conf.

Default value: 6.

our_to_self_delay: u16

Set to the number of blocks we require our counterparty to wait to claim their money (ie the number of blocks we have to punish our counterparty if they broadcast a revoked transaction).

This is one of the main parameters of our security model. We (or one of our watchtowers) MUST be online to check for revoked transactions on-chain at least once every our_to_self_delay blocks (minus some margin to allow us enough time to broadcast and confirm a transaction, possibly with time in between to RBF the spending transaction).

Meanwhile, asking for a too high delay, we bother peer to freeze funds for nothing in case of an honest unilateral channel close, which implicitly decrease the economic value of our channel.

Default value: BREAKDOWN_TIMEOUT, we enforce it as a minimum at channel opening so you can tweak config to ask for more security, not less.

our_htlc_minimum_msat: u64

Set to the smallest value HTLC we will accept to process.

This value is sent to our counterparty on channel-open and we close the channel any time our counterparty misbehaves by sending us an HTLC with a value smaller than this.

Default value: 1. If the value is less than 1, it is ignored and set to 1, as is required by the protocol.

max_inbound_htlc_value_in_flight_percent_of_channel: u8

Sets the percentage of the channel value we will cap the total value of outstanding inbound HTLCs to.

This can be set to a value between 1-100, where the value corresponds to the percent of the channel value in whole percentages.

Note that:

• If configured to another value than the default value 10, any new channels created with the non default value will cause versions of LDK prior to 0.0.104 to refuse to read the ChannelManager.

• This caps the total value for inbound HTLCs in-flight only, and there’s currently no way to configure the cap for the total value of outbound HTLCs in-flight.

• The requirements for your node being online to ensure the safety of HTLC-encumbered funds are different from the non-HTLC-encumbered funds. This makes this an important knob to restrict exposure to loss due to being offline for too long. See ChannelHandshakeConfig::our_to_self_delay and ChannelConfig::cltv_expiry_delta for more information.

Default value: 10. Minimum value: 1, any values less than 1 will be treated as 1 instead. Maximum value: 100, any values larger than 100 will be treated as 100 instead.

negotiate_scid_privacy: bool

If set, we attempt to negotiate the scid_privacy (referred to as scid_alias in the BOLTs) option for outbound private channels. This provides better privacy by not including our real on-chain channel UTXO in each invoice and requiring that our counterparty only relay HTLCs to us using the channel’s SCID alias.

If this option is set, channels may be created that will not be readable by LDK versions prior to 0.0.106, causing ChannelManager’s read method to return a DecodeError::InvalidValue.

Note that setting this to true does not prevent us from opening channels with counterparties that do not support the scid_alias option; we will simply fall back to a private channel without that option.

Ignored if the channel is negotiated to be announced, see ChannelHandshakeConfig::announced_channel and ChannelHandshakeLimits::force_announced_channel_preference for more.

Default value: false. This value is likely to change to true in the future.

announced_channel: bool

Set to announce the channel publicly and notify all nodes that they can route via this channel.

This should only be set to true for nodes which expect to be online reliably.

As the node which funds a channel picks this value this will only apply for new outbound channels unless ChannelHandshakeLimits::force_announced_channel_preference is set.

Default value: false.

commit_upfront_shutdown_pubkey: bool

When set, we commit to an upfront shutdown_pubkey at channel open. If our counterparty supports it, they will then enforce the mutual-close output to us matches what we provided at intialization, preventing us from closing to an alternate pubkey.

This is set to true by default to provide a slight increase in security, though ultimately any attacker who is able to take control of a channel can just as easily send the funds via lightning payments, so we never require that our counterparties support this option.

The upfront key committed is provided from KeysInterface::get_shutdown_scriptpubkey.

Default value: true.

Trait Implementations

impl Clone for ChannelHandshakeConfig

fn clone(&self) -> ChannelHandshakeConfig

Returns a copy of the value.

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

Performs copy-assignment from source.

impl Debug for ChannelHandshakeConfig

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

Formats the value using the given formatter.

impl Default for ChannelHandshakeConfig

fn default() -> ChannelHandshakeConfig

Returns the “default value” for a type.

impl Copy for ChannelHandshakeConfig