Favorite Non-Default lnd.conf Settings \ stacker news ~lightning

3590 sats \ 19 comments \ @zapomatic 3 Jan lightning

Hello fellow node operators. What are you favorite lnd.conf non-default updates?

There is Plebnet's list: https://plebnet.wiki/wiki/LND_Configuration_Settings which has some obvious things like enabling watchtowers

and some others like routerrpc.minrtprob=0.005

but what else are ya'll doing?

Zap-O-Matic has noticed quite a lot of disconnected channels recently (WalletOfSatoshi seems down ALL THE FRIGGIN TIME). So we are looking to cut these defaults in half:

; The duration that a peer connection must be stable before attempting to send a
; channel update to re-enable or cancel a pending disables of the peer's channels
; on the network. 
; chan-enable-timeout=19m

; The duration that must elapse after first detecting that an already active
; channel is actually inactive and sending channel update disabling it to the
; network. The pending disable can be canceled if the peer reconnects and becomes
; stable for chan-enable-timeout before the disable update is sent.
; chan-disable-timeout=20m

chan-enable-timeout=9m
chan-disable-timeout=10m

Do you have custom settings for these? Have you had experience with having them smaller? What else is not great as a default?

view all related items

2769 sats \ 6 replies \ @benthecarman 3 Jan

You should change your coin selection to random, otherwise it currently defaults to selecting your largest utxos. The default is terrible for privacy and will grind your utxos to dust overtime.

10 sats \ 3 replies \ @031ca302ff 3 Jan

Except when your node has to CPFP anchors or stage 1 sweep htlcs. Carrying an extra input utxo (or 5) at 200 s/vB because it didn’t select a utxo big enough is pretty painful.

IMO, if privacy is the goal, avoid using the hot wallet altogether.

0 sats \ 2 replies \ @benthecarman 3 Jan

You only need like 10-20k sats to bump, if you have utxos smaller than that, that is probably a problem

0 sats \ 1 reply \ @031ca302ff 4 Jan

Here’s 2 examples from FCs from a few hours ago.

This CPFP needed 2 utxo, where the 2nd was big enough to go solo had it used largest selection - https://mempool.space/tx/d46cedf4e5b85dfde09b4ee4cfb713214e0956a6d6c932caf39195f0faa9bb65

Here is a 6 utxo CPFP (maybe they didn’t have a utxo large enough) - https://mempool.space/tx/039ae9e76659454b59412fb6cc63e22dfe621f967d22e424a953d8984430f1da

0 sats \ 0 replies \ @benthecarman 4 Jan

oof paying 175k sats ($75) just to fee bump their anchor. definitely needs better fee estimation, mempool space is saying their effective fee rate is 4x over

1 sat \ 0 replies \ @zapomatic OP 3 Jan

wow... that's a great call

; The strategy to use for selecting coins for wallet transactions. Options are
; 'largest' and 'random'.
; coin-selection-strategy=largest

added coin-selection-strategy=random to my conf :)

0 sats \ 0 replies \ @niftynei 3 Jan

is it still the default? rough

100 sats \ 3 replies \ @Hakuna 9 Jan

Sharing only the ones I saw a number of runners not leveraging

[Application Options]
# Number of logfiles that the log rotation should keep. Setting it to 0 disables deletion of old log files.
maxlogfiles=20

# Max log file size in MB before it is rotated.
maxlogfilesize=300

maxbackoff=5m
max-commit-fee-rate-anchors=200
payments-expiration-grace-period=10000h

gc-canceled-invoices-on-startup=true
gc-canceled-invoices-on-the-fly=true

sync-freelist=false

[bolt]
db.bolt.auto-compact=true
db.bolt.auto-compact-min-age=730h

[Bitcoind]
bitcoind.estimatemode=ECONOMICAL

[healthcheck]
healthcheck.torconnection.attempts=3
healthcheck.torconnection.timeout=10s
healthcheck.torconnection.backoff=30s
healthcheck.torconnection.interval=1m
healthcheck.chainbackend.attempts=3
healthcheck.chainbackend.timeout=2m0s
healthcheck.chainbackend.interval=1m30s

[sweeper]
# Duration of the sweep batch window. The sweep is held back during the batch
# window to allow more inputs to be added and thereby lower the fee per input.
# Careful for the HTLCs of an FC with incoming=true, you can only batch those with
# incoming=false (which are yours)
sweeper.batchwindowduration=1000h
# sweeper.batchwindowduration=10m

0 sats \ 2 replies \ @zapomatic OP 9 Jan

Thanks for sharing. That sweeper.batchwindowduration is a huge shift from the default of 30s :)

100 sats \ 1 reply \ @Hakuna 9 Jan

It's just as long as the last outgoing HTLC expiry, and since I'm lazy, I keep it at 10,000hrs. This is specifically helpful if you have FCs with pending HTLCs, since each of them needs to go onchain. If those are mostly outgoing, I stay at 10,000hrs and switch to 10 minutes, restart LND when the fees are low are all pending HTLCs are mature. In a result, those pending HTLCs get batched into one tx, hence saving you onchain costs.

Then back to 10,000hrs.

0 sats \ 0 replies \ @zapomatic OP 9 Jan

brilliant.

0 sats \ 0 replies \ @zapomatic OP 6 Jan

Just dropping an update that I reverted my override of the timeout settings. I'm not sure if this is what did it, but I had some issues with my wiregaurd/VPN provider and had to reboot today after getting thrown into tor-only mode. I think increasing the polling and offline/online states was getting to be too much and ended up overloading something. Not 100% sure that's what did it, but that was the significant change I made in the last day.

0 sats \ 0 replies \ @justin_shocknet 3 Jan

bitcoin.minhtlc=10000

0 sats \ 0 replies \ @nullcount 3 Jan

https://lh4.ggpht.com/_tlPT8GKFDDA/THNRYljeAEI/AAAAAAAAAHA/JkDOYphmMmE/wumbo.png

0 sats \ 2 replies \ @zapomatic OP 3 Jan

Another one that seems like it might be worth changing:

; The polling interval between attempts to detect if an active channel has become
; inactive due to its peer going offline.
; chan-status-sample-interval=1m

setting this to 30s would allow your node to detect offline channels faster at a cost of more checks. Would it be crazy to cut this in half?

0 sats \ 1 reply \ @zapomatic OP 3 Jan

chan-status-sample-interval=1m

verifying a rumor from telegram:

pay attention with these settings. chan-disable-timeout, chan-enable-timeout and chan-status-sample-interval I think must match in a certain way (x + y < z) I read somewhere or else LND doesn't startup anymore

in which case, this should work:

chan-enable-timeout=9m
chan-disable-timeout=10m
chan-status-sample-interval=45s

0 sats \ 0 replies \ @zapomatic OP 5 Jan

chan-enable-timeout https://github.com/lightningnetwork/lnd/issues/5518

chan-status-sample-interval + chan-enable-timeout <= chan-disable-timeout

0 sats \ 1 reply \ @zapomatic OP 3 Jan

Another one I'm thinking of adding:

; The timeout value for network connections.
; Valid units are {ms, s, m, h}.
; connectiontimeout=2m

to connectiontimeout=4m because I have a tor peer that kept dropping off because it went beyond the 2000ms ping latency. Anyone think this is dangerous to increase?

0 sats \ 0 replies \ @zapomatic OP 3 Jan

haha. I just realized it's set by default to 2m, not 2s... maybe that tor ping latency falloff is a different setting.