Node
Parameters
derive private keys and secrets from your seed.
name of the lightning node.
features supported by the lightning node.
threshold below which outputs will not be generated in commitment or HTLC transactions (i.e. HTLCs below this amount plus HTLC transaction fees are not enforceable on-chain).
maximum dust limit we let our peer use for his commitment (in theory it should always be 546 sats).
on-chain feerates that will be applied to various transactions.
cap on the total value of pending HTLCs in a channel: this lets us limit our exposure to HTLCs risk.
cap on the number of pending HTLCs in a channel: this lets us limit our exposure to HTLCs risk.
cltv-expiry-delta used in our channel_update: since our channels are private and we don't relay payments, this will be basically ignored.
number of blocks necessary to react to a malicious peer that doesn't acknowledge and sign our HTLC preimages.
delay in seconds before we check for timed out HTLCs in our channels after a wallet restart.
minimum accepted htlc value.
number of blocks our peer will have to wait before they get their main output back in case they force-close a channel.
maximum number of blocks we will have to wait before we get our main output back in case we force-close a channel.
minimum depth of a transaction before we consider it safely confirmed.
base fee used in our channel_update: since our channels are private and we don't relay payments, this will be basically ignored.
proportional fee used in our channel_update: since our channels are private and we don't relay payments, this will be basically ignored.
size of the channel reserve we required from our peer.
maximum size of the channel reserve our peer can require from us.
delay after which we disconnect from our peer if they don't send us a revocation after a new commitment is signed.
timeout for the connection authentication phase.
timeout for the connection initialization phase.
delay between ping messages.
timeout when waiting for a response to our ping.
disconnect when a peer doesn't respond to our ping.
automatically reconnect to our peers.
delay before which we reconnect to our peers (will be randomized based on this value).
maximum delay between reconnection attempts.
bitcoin chain we're interested in (testnet or mainnet).
channel flags used to temporarily enable or disable channels.
our Bolt 11 invoices will only be valid for this duration.
number of seconds we will wait to receive all parts of a multi-part payment.
minimum channel size.
maximum channel size.
maximum number of retries when attempting an outgoing payment.
enable trampoline payments.