Good morning Subhra,
> 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?
This event is emitted when an incoming HTLC is irrevocably committed.
This is a hook, and what happens will depend on what the hook returns:
* It returns `{"result":"continue"}`: normal processing of the HTLC (forward,
fail, or claim as normal operation).
* It returns `{"result":"fail", "failure_message": "2002"}`: fail the HTLC with
the given failure message, failure message is a hex-encoded failure blob, see
BOLT 4 for how.
* It returns `{"result": "resolve", "payment_key":
"0000000000000000000000000000000000000000000000000000000000000000"}`: claim the
HTLC regardless of whether it is a forward or terminates here, the given
`payment_key` is the 64-hex-digits encoding of the preimage.
For the most part, for purposes of griefing, you can just delay the default
`{"result":"continue"}` for as long as you want to grief the payment, this will
work for both forwards and payment receives correctly, except griefed.
See [our docs](https://lightning.readthedocs.io/PLUGINS.html#htlc-accepted) for
more.
Regards,
ZmnSCPxj
>
> On Tue, Mar 24, 2020 at 1:57 PM ZmnSCPxj <[email protected]> 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.
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
