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

[Subhra Mazumdar]

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? 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?

On Tue, Mar 24, 2020 at 1:57 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Subhra,
>
> > Hi,
> >     I was just playing around with LND and established a channel between
> 2 parties A and B. When sending a payment to B via HTLC, B adds an invoice
> and over here I used a different payment hash for A for sendpayment with a
> delta of 144 blocks. The error I got on initiating send payment is
> "incorrect or unknown payment details". So what is exactly happening here?
> Is B ignoring any formation of HTLC between them?
>
> A and B form an HTLC in them, to the point that it is "irrevocably
> committed".
> It is a recommendation of BOLT spec that you pretty much do not do
> anything until an incoming HTLC reaches "irrevocably committed" state.
>
> Then, B looks at the HTLC data.
> If B knows the preimage to the payment hash, it claims the HTLC
> immediately as soon as it is irrevocably committed.
>
> If B does not know the preimage, it checks if there is forwarding data.
> If there is no forwarding data (B is the final hop) then B responds with
> "incorrect or unknown payment details", then A waits for the channel state
> to advance so that the HTLC getting removed reaches "irrevocably
> committed", then reports the failure to the user.
>
> > I hope in this case no money gets locked in this case.
>
> Money got locked temporarily int the HTLC, but was freed very soon
> afterwards, as fast as B and A can advance the channel state (which is
> limited by your hardware and network speeds).
>
>
> > Then how can one mimic griefing attack scenario (B refusing to release
> the correct preimage) in LND?
>
> You may need to modify LND code directly, or ask LND devs if there are any
> such hooks available.
>
> In C-Lightning, you will have to install a plugin, devise some way for the
> plugin to know of what payment hash you want to grief, then have the plugin
> hook into `htlc_accepted`.
> In `htlc_accepted` handler, if the incoming HTLC has a payment hash
> matching what you want to grief, you then perform a `waitblockheight`
> command to wait for the target block height you want to grief for, then
> return from the `htlc_accepted` handler.
> (This can be complicated by the exact language you use to implement the
> plugin, remember the plugin should be async so it should still respond with
> `{"result":"continue"}` immediately to other incoming `htlc_accepted` as
> normal, if you implement the plugin in Python the Python C-Lightning plugin
> library should "just work" as far as I know as it transforms the Python
> into an async language, but ask cdecker for that; but if you have a
> sufficiently monadic framework for asynchronicity (a la Javascript
> `Promise`/Haskell `IO`) it should work like that.)
>
> Regards,
> ZmnSCPxj
>


-- 
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200324/92fb1048/attachment-0001.html>