pull down to refresh

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

Thanks for sharing. That sweeper.batchwindowduration is a huge shift from the default of 30s :)
reply
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.
reply
brilliant.
reply