Expose htlc id to htlc_accepted hook

[fiatjaf]

I believe this is necessary for low-level stuff that deals with MPP, for example, although I am not entirely sure.

[cdecker]

Not quite sure what the use here would be, as pay already implements the MPP receiving logic without requiring this extra information. However, I'm also not opposed to including it as it can have use-cases (accounting making sure we didn't miss an HTLC for example?).

[fiatjaf]

If one is implementing a bridge between two networks they must be able to relay multiple HTLCs with the same payment hash, and because of that they should be able to know which one to fail/fulfill based on the id, not the payment hash.

Or I could have misunderstood everything.

[cdecker]

I think you can track them yourself: each HTLC is a hook call. In the hook handler you can assign any unused partid for the HTLC you insert into the other node, it doesn't have to match the one in the incoming part at all. You then wait or poll with the partid you chose and then relay the result by returning from the hook handler.

Also come to think of it the HTLC id and the partid are inherently different concepts, one is a monotonic increasing counter for HTLCs on that channel and the other is a differentiator for the sender to know which part it is tracking in the context of a payment. Notice also that if you happen to forward HTLCs from two different incoming channels you may end up with HTLC id collisions which would be hard to debug.

[fiatjaf]

But I don't get the partid as part of the htlc_accepted hook. partids are only visible to the sender and the receiver, no?

Imagine I get two htlc_accepted calls for the same hash, cltv expiry and amount from the same channel A to be relayed to the same channel B. The only way I can differentiate the two is by the JSONRPC message I got each, which would be fine except for the fact that if I go offline I'll receive these two htlc_accepted again and now I don't know which one is which.

Notice also that if you happen to forward HTLCs from two different incoming channels you may end up with HTLC id collisions which would be hard to debug.

Yes, but I can easily track them by [channel_id, htlc_id].

[cdecker]

Oh, I see this is related to being able to distinguish them and associate them with downstream effects, without having to differentiate them by amount which may also have a collision. Very good catch, I didn't see this :-)

Sounds good to me ^^

Do you mind adding a tiny Changelog-Added to your commit message so it'll show up in the changelog on release too?

ACK b3bb188

[fiatjaf]

OK, done!

[vincenzopalazzo]

ACK 94522c5

[fiatjaf]

OK, I've also added the incoming short_channel_id now as I just realized that wasn't present.

[rustyrussell]

Good catch!

Ack 5404c20