Return incorrect_or_unknown_payment_details if a payment hash cannot be found in the federation

[elsirion]

Some services use HTLCs with random payment hashes for probing to figure out fees ahead of time. We currently seem to return an error other than incorrect_or_unknown_payment_details in that case, which makes this fail.

[nordbjorn]

Here is a relevant example of how Breez implements this handling: https://github.com/breez/lspd/blob/086f78a08b23d6c7f67793e659dce5438a005f7e/interceptor/intercept_handler.go#L119-L140

[TonyGiorgio]

I think the problem here is that the intermediate node (ie, gateway in the routing hint) is returning the error. Since the client created the invoice, this presents some problems. The basic/naive probing method is to make sure the payment made it to the last hop and then checking for incorrect_or_unknown_payment_details, but in the fedimint/breez case, it doesn't go that far.

The proposal on the call today was either:

• Pass the client secret to the federation so they can create the onion error.
• Go the breez way and make the gateway give the same incorrect_or_unknown_payment_details error.

When I worked for a custodian a few years back, people would hardcode Breez's pubkey for their probing logic. I wonder if this is standard enough now that probers always accept incorrect_or_unknown_payment_details from either the node pubkey from the invoice signature or from any nodes in the route hint. Will try to look at a few FOSS wallets to see how they behave. Might want to talk to a few custodians like Strike or River or to the LN Mailling List to see if there's enough consensus now around probes to LSPs.

[nordbjorn]

When I worked for a custodian a few years back, people would hardcode Breez's pubkey for their probing logic. I wonder if this is standard enough now that probers always accept incorrect_or_unknown_payment_details from either the node pubkey from the invoice signature or from any nodes in the route hint. Will try to look at a few FOSS wallets to see how they behave. Might want to talk to a few custodians like Strike or River or to the LN Mailling List to see if there's enough consensus now around probes to LSPs.

You can draw the conclusion that you are dealing with an interceptor node by looking at the channel ID of the route hint in the invoice. Since the channel ID contains the block height of the funding transaction, you can determine if this is a valid/possible block height.

If you draw the conclusion that the destination is behind an interceptor node, you can also expect the incorrect_or_unknown_payment_details to come from the interceptor node.

But always accepting the error from either the destination or from the route hint might also make sense.

[justinmoon]

I was told lightningnetwork/lnd#8136 may help with probing on LND, and this is the most related issue we have cc @m1sterc001guy @okjodom

[TonyGiorgio]

Dev call: LND will help, if custodians change, but the real fix will be to let the gateway generate the invoice which is needed anyways for other reasons.