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
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
