[Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND

[ZmnSCPxj]

Good morning Subhra,

> Another question related to the paper https://arxiv.org/abs/2003.00003. Over here, it is stated in page 13, "Surge of unresolved HTLCs while probing: Recalling steps 5-7 in Figure 4, each probe sets up a chain of irredeemable HTLCs (since a matching preimage would have to be brute-forced). Eventually, running multiple probes over the same channels will escrow its funds in these HTLCs, effectively DOSing the probe route and forcing the nodes to wait until the HTLCs time out before being able to forward other payments. This is an issue we encountered over and over during 4.2 and 4.3, often giving us one shot at probing before having to wait multiple hours for the HTLCs to expire. This is also why we chose the channels leading up to our final target to have a much higher balance, so that we would have enough.." So there was no matching preimage with receiver as per Fig 4. So that means in the route say A->B->C->D, if D doesn't have a matching preimage and suppose C->D uses lock time of 144 blocks, B->C 288 blocks and A->B uses a locktime of 432 blocks, so won't be the case funds in A->B and B->C still remains locked for the mentioned locktime?

It is helpful to remember that inside a channel, every contract has an implicit branch "if both of us in this channel agree, we can spend this contract funds any way we want".

This is because every contract is dependent on a transaction spending from a 2-of-2, and both parties can always sign a new 2-of-2 transaction without that contract --- it is just that both have to agree to do this.

In case of a reported failure, the receiving node in the channel basically says "just between the two of us, I will not be able to claim this HTLC using the hashlock branch anyway because <BOLT 4 failure code reason>, so this will inevitably be claimable to you in the timelock anyway, so we might as well just agree to re-assign the HTLC funds back to you right now".

The sending node is then willing to sign off on this outside-of-the-contract agreement, since it lets it get the funds back before the timelock expires, and to reuse those funds otherwise.

Thus, even if D griefs up to 143 blocks it wants, at the 144th block C can report immediately back to B and then A with the above failure mechanism.

B and C are incentivized to do this quickly since it would allow the funds to be reused again in a different, probably-will-not-be-griefed near-future payment, which might earn them fees in the future.

Thus if B and C are not controlled by the A+D conglomerate then they have no incentive to extend the griefing attack further.

Of course, if either B or C is offline at the time, then the new state where the HTLC is removed out-of-contract is not possible to sign with both parties.

> I know this is not the definition of griefing attack but then can this possibly mimic the situation where receiver denies having the correct preimage?

No, since B and C are incentivized to report this immediately in order to free up the funds in order for them to forward "soon".

Regards,
ZmnSCPxj