From subhra.mazumdar1993 at gmail.com Tue Mar 24 16:15:21 2020 From: subhra.mazumdar1993 at gmail.com (Subhra Mazumdar) Date: Tue, 24 Mar 2020 21:45:21 +0530 Subject: [Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND In-Reply-To: References: Message-ID: Hi ZmnSCPxj, Thank you for the explanation. So I went through BOLT 04 specification and quoting a few error possibilities: An *intermediate hop* MUST NOT, but the *final node*: - if the payment_secret doesn't match the expected value for that payment_hash, or the payment_secret is required and is not present: - MUST fail the HTLC. - MUST return an incorrect_or_unknown_payment_details error. - if the payment hash is unknown: - MUST fail the HTLC. - MUST return an incorrect_or_unknown_payment_details error. So it is the final node which is expected to fail the htlc in these 2 cases. But then what if final node denies revealing the secret? Say in the scenario A->B->C->D, D doesn't reveal the secret. So in such a case, what is C supposed to do? Shall it resort to condition no. 1( secret doesn't match), generate an error message and unlock funds of A->B and B->C as soon as possible? On Tue, Mar 24, 2020 at 4:57 PM ZmnSCPxj wrote: > 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 , 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 > > -- Yours sincerely, Subhra Mazumdar. -------------- next part -------------- An HTML attachment was scrubbed... URL: