From subhra.mazumdar1993 at gmail.com Tue Mar 24 08:56:05 2020 From: subhra.mazumdar1993 at gmail.com (Subhra Mazumdar) Date: Tue, 24 Mar 2020 14:26:05 +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: Thanks ZmnSCPxj. Just a clarification on the idea proposed so that means here B needs to delay the HTLC acceptance? Pardon my knowledge on c-lightning, but what exactly happens upon htlc_acceptance? Release of preimage or just an acknowledgment by B reaching to the point of irrevocably committed? On Tue, Mar 24, 2020 at 1:57 PM ZmnSCPxj 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: