ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-03-24 📝 Original message: Good morning Subhra, > ...
📅 Original date posted:2020-03-24
📝 Original message:
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
📝 Original message:
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