Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-03-24 📝 Original message: Thanks ZmnSCPxj. Just a ...
📅 Original date posted:2020-03-24
📝 Original message:
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 <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/2abe534f/attachment.html>;
📝 Original message:
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 <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/2abe534f/attachment.html>;