How many blocks before its earliest HTLC expiry LND is assumed to cancel an
accepted HOLD invoice by itself. LND’s invoices.holdexpirydelta defaults
to 18 since v0.21 (16 + 2) and 12 before, has no upper bound, and cannot be
read cheaply before v0.21 (GetDebugInfo returns the whole log), so this
assumes twice the current default. The excess also absorbs blocks found
between the deadline check and settlement. It costs nothing for a payment
handled promptly, which still has about 108 blocks left under
LNV2_HOLD_INVOICE_CLTV_EXPIRY.
Final CLTV delta of the HOLD invoices created for LNv2 receives. Left unset,
LND would use its routing bitcoin.timelockdelta, which operators may lower
to 24 (18 before v0.21), leaving only a few blocks between accepting a
payment and LND cancelling it by itself invoices.holdexpirydelta blocks
before expiry. LND rejects any HTLC expiring sooner than this many blocks
after it arrives, so it bounds every accepted HTLC, not just honest payers.
Whether a HOLD invoice accepted an HTLC without an MPP total. For the
non-blinded HOLD invoices the gateway creates, standard LND builds require
the payment address, which travels in the MPP record, from every HTLC
except one carrying a keysend record. Since LND v0.20.3 and v0.21.2 that
record must hold the invoice’s preimage; before, any value passes unless
accept-keysend is on.
Block height at which LND is assumed to cancel an accepted HOLD invoice by
itself, LND_ASSUMED_HOLD_EXPIRY_DELTA blocks before its earliest accepted
HTLC expires, after which the gateway can no longer settle it. Without an
accepted HTLC there is no deadline to trust, so it is 0.
The hex preimage of an LND invoice, if LND knows it. A HOLD invoice has no
preimage until it is settled, so r_preimage is empty while one is pending
or after it was canceled.