HTLC fulfillment flow does not give signer timely validation information

[devrandom]

When fulfilling an HTLC, LDK removes the incoming (previous-hop) one first and does not provide a preimage to the signer. This makes it impossible for a validating signer to ensure no funds are lost.

the options are, in order of preference:

• remove the outgoing (next-hop) HTLC first, and provide the preimage during the first related signing operation
• continue removing the incoming (previous-hop) HTLC first, and provide the preimage during the first related signing operation

The first option will simplify the signer logic, because it will maintain the invariant that incoming value is always >= outgoing value.

Logs from a relevant functional test of LDK+VLS are here: https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/331

[TheBlueMatt]

Because we remove the inbound edge in response to the update_fulfill_htlc rather than after the commitment dance from the outbound edge (and I don't think we want to change that) it'd be kinda hard to remove the outbound edge first. Thus, we'll just want to provide the preimage for local removes on the claim.

[TheBlueMatt]

Alternatively, we could just provide the preimage "raw" in the outgoing channel to indicate that the claim is "in-progress", but that's a bit confusing cause the claim could revert after a reconnect (at which point we get free money).

[devrandom]

Alternatively, we could just provide the preimage "raw" in the outgoing channel to indicate that the claim is "in-progress", but that's a bit confusing cause the claim could revert after a reconnect (at which point we get free money).

well, either way. we don't care when we get the preimage, as long as it's before the incoming HTLC disappears. we just want to be able to tell that the incoming now belongs to us, and when it goes away we can ensure that our balance in that channel has increased by that amount, which keeps the payment balanced.

[TheBlueMatt]

Sadly 0.0.117 exploded into a million tasks and this just isn't likely in the next few weeks if we want to get other important fixes out ASAP.

[TheBlueMatt]

Sorry, somehow this totally slipped off my plate. I think we do already provide the relevant preimage - EcdsaChannelSigner::sign_counterparty_commitment has a preimages argument which should always include the preimage for the removed HTLC. Does that suffice for what you need, or is there more (eg the hash or HTLC id) or is that not working in practice?

[devrandom]

right, I added that back in 2022. I think this issue was opened because the preimages are not actually provided when the incoming HTLC is removed.

[TheBlueMatt]

Oh, no, you're right, they're not provided. So the rationale we had is we were only providing preimages for outgoing HTLCs since that's what the counterparty is providing us. However, for incoming HTLCs we didn't provide the preimages since they're driving a balance increase, and we were assuming that the signer would always happily accept a balance increase (and compare that later against the decrease from a counterparty claim). If that's not the case, its rather trivial to also provide the inbound HTLC preimages.

[devrandom]

it's not trivial to correlate the balance increase with the HTLC disappearing. there may be multiple HTLCs being added and removed. it's much easier to do the accounting on a per-HTLC basis than to try to figure out the global balance.

[TheBlueMatt]

Right, I was thinking that you'd compare the set of HTLCs in each commitment transaction to figure that out, which I believe we do provide in full.

[devrandom]

but if we don't get the preimages at that point, we don't know which HTLCs are disappearing because failed and which are disappearing because fulfilled, which complicates the validation.

[TheBlueMatt]

Mmm, right, its still napscack. Anyway, #2753 should fix it for you.

[devrandom]

great!