[feature]: configure interceptdelta in lnd.conf (#6831)

[antonilol]

Is your feature request related to a problem? Please describe.

the feature added in #6831 can cause held htlcs where the preimage is not known yet (in some on chain swap for example) to be failed by lnd (when the taker of the swap deliberately wants this to happen). this can cause partial settlement and loss of funds

Describe the solution you'd like

a way to configure this value or turn this feature off

Describe alternatives you've considered

not upgrading to v0.16..., not really an alternative

Additional context

[Roasbeef]

Should be simple enough to make a config flag, the default is DefaultCltvInterceptDelta.

In your example case, is it that the application knows the the pre-image is coming eventually? This new feature was added as a safeguard against unwanted force closures.

[antonilol]

In your example case, is it that the application knows the the pre-image is coming eventually?

In my case (the swap), the preimage can come from an on chain spend (not necessarily bitcoin). When both lockups have been done the taker "decides" when the preimage is available for the swap service to settle the htlc with.

[joostjager]

Given an htlc that expires at height x, at which height would you no longer attempt to sweep with the preimage? Normally a safety margin is required to ensure that a preimage sweep is confirmed before htlc expiry. Otherwise a race could occur where the peer tries to timeout the htlc too.

The htlc interceptor watchdogs auto-fails at some point, but for safe operation, I don't think there are many more blocks that you could wait longer?

For swaps, the outgoing on-chain htlc should have long been timed out at that point?

[antonilol]

Given an htlc that expires at height x, at which height would you no longer attempt to sweep with the preimage?

x - n, where n is the amount of blocks to get my tx confirmed, if someone controls a miner n is 1 (or pays 0.03682719 btc to a miner)

For swaps, the outgoing on-chain htlc should have long been timed out at that point?

It should, but for whatever reason the transaction did not confirm yet, and failing the htlc at that point could cause partial settlement (with help from a miner).

in this case of a swap service, the swap service should fail the htlc whenever it thinks the on chain htlc timeout transaction has enough confirmations to not be reversed. i think for most users this feature helps to get less force closes when forgetting to send a 'fail' to the interceptor, but for this specific purpose lnd doesn't help with failing the htlc, so i like this new feature to be configurable

[joostjager]

Ok, got it. In this case it is then probably best to disable auto-fail completely and let lnd never do anything until the counterparty really force-closes the channel.