search

lightningnetwork / lnd

Lightning Network Daemon ⚡️
MIT License
7.65k stars 2.07k forks source link

fwdinghistory doesn't include HTLCs settled using HTLC interceptor RPC #4910

Open champo opened 3 years ago

champo commented 3 years ago

Background

At Muun we're using the HTLC interceptor RPC to settle HTLCs for our implementation of reverse swaps. I'm trying to determine whether the HTLC was properly claimed after the RPC call, but the fwdinghistory CLI command doesn't seem to include these HTLCs. In my tests, the HTLC seems to have been claimed by lnd since the sender received the preimage and the channel balances changed, but there seems to be no other record of this operation.

Your environment

Expected behaviour

See the HTLCs in the fwdinghistory for accounting purpouses.

Actual behaviour

They don't show up.

champo commented 3 years ago

I also see no mention of the preimageBeacon logs that indicate the preimage has been recorded, which seems weird.

Roasbeef commented 3 years ago

In my tests, the HTLC seems to have been claimed by lnd

If they were claimed by the lnd node under your control, then this isn't actually a forward. As a result, it won't come across as a forward since your node is the terminal node (you received the payment).

champo commented 3 years ago

They are a forward since the next step of the route was claimed by another node (just not a full BOLT compliant node). But rather than argue semantics, what I'd like is to understand where this claim is reflected and how to access it for accounting purpouses. The HTLC intercept API has no feedback on whether the SETTLE command was successful and we could simply be loosing funds and we have no way to find out AFAICT.

Roasbeef commented 3 years ago

It isn't a question of semantics given both the outgoing edge wasn't fully specified in the onion itself, as your system resolves it manually. A forward as defined within lnd is something that enters and exits lnd via the existing automated process, you've added an entirely new flow. Therefore the class of transactions you're referring to won't show up in ForwardingHistory at the outgoing edge is essentially "unknown".

As a result, you'll need to externally account for this "special" case as lnd doesn't understand (nor does it need to really) what you're doing at a higher level.

If you want to track this progress externally, you can use the ScubrscribeHtlcEvents call on the router-rpc sub-server. You'll be able to view all HTLC progress from the PoV of the link (the channel) rather than the switch.

champo commented 3 years ago

the outgoing edge wasn't fully specified in the onion itself

I think you have a misconception here. In our impl the outgoing edge is specified in the onion, LND is not the last hop of the onion but rather the previous one. We are simply implementing the outgoing link via HTTP. All the data ForwardingHistory needs is present, which is why I expected to find those HTLCs there.

As a result, you'll need to externally account for this "special" case as lnd doesn't understand (nor does it need to really) what you're doing at a higher level.

I dont understand this rationale. As I see it money gets shuffled around by the node and that should be recorded somewhere. It might be "special", but it still is a transaction executed by LND.

ScubrscribeHtlcEvents

Perfect! We can make do with that.