Consider allowing for BOLT12 payments over unannounced channels

[tnull]

Currently, we only allow for BOLT12 payments if the introduction point is an announced announced node both payer and payee are connected to. It is my understanding that this is at least partially intentional to discourage leaking the payer's IP to the payee.

However, this makes for an unexpected UX where users could send payments via an intermediate node, but not via a directly-connected private channel.

It would be nice if we could reconsider if we could relax some of the checks along the lines of tnull@8138bec, or, at least allow the user to opt into private-channel BOLT12 payments via a config option.

[TheBlueMatt]

The proposed patch would break the general case - we'd generate blinded paths starting with a private node and give those out publicly (which most nodes wouldn't be able to pay). Indeed, if we have no peers with public channels (?????) we should maybe not spuriously fail, but I don't think that would quite address the issue you're talking about here (where we have public channels, but also a private one with another node).

I'm not sure how we could handle this case properly. If the peer gives us a one-hop reply path we could detect it explicitly and give them a one-hop payment path, but that assumes they give us a one-hop reply path, and I'm not sure we even want to - a user receiving a BOLT12 payment may have some expectation for marginal privacy, so we'd be breaking it for some subset of senders, but that's fairly surprising.

[tnull]

The proposed patch would break the general case - we'd generate blinded paths starting with a private node and give those out publicly (which most nodes wouldn't be able to pay). Indeed, if we have no peers with public channels (?????) we should maybe not spuriously fail, but I don't think that would quite address the issue you're talking about here (where we have public channels, but also a private one with another node).

Yes, the linked patch was just a quick fix I applied to the experimental branch used for the recent LDK Node hackathon to easily enable BOLT12 sending in ~local regtest/signet setups. Always requiring the introduction point to be announced is pretty confusing in these kind of scenarios, especially if we have a direct (possibly even public) channel open but fail the payment due to not having received the node announcement yet. And of course, if the node was configured to use RGS, it would always ignore that node announcement, so even if the introduction point is announced it first has to be picked up and included in the next RGS snapshot.

I'm not sure how we could handle this case properly. If the peer gives us a one-hop reply path we could detect it explicitly and give them a one-hop payment path, but that assumes they give us a one-hop reply path, and I'm not sure we even want to - a user receiving a BOLT12 payment may have some expectation for marginal privacy, so we'd be breaking it for some subset of senders, but that's fairly surprising.

Right, I'm also not entirely sure how to solve this, but I think we need to do something, as there are just a lot of requirements and assumptions here that need to go the right way to allow a BOLT12 payment to be successfully sent, and in every other scenario we would fail the payment, often not returning an error at all (i.e., when it fails in the flow somewhere after the initial step constructing an invoice request).

[TheBlueMatt]

in ~local regtest/signet setups

For these we could simply relax the requirement that you have a public channel? Maybe that would suffice in many cases.

And of course, if the node was configured to use RGS, it would always ignore that node announcement, so even if the introduction point is announced it first has to be picked up and included in the next RGS snapshot.

I imagine in most real cases this won't be an issue? You are generally opening a channel with an LSP who has been around for a while. We should definitely improve the error messaging in this case, though, because we can control this top-to-bottom for offer/invoice_request generation (its all local, not messages going into a blackhole) we can provide a useful error message that describes some common cases.

For invoice generation we should also maybe consider some kind of error sentinel - eg an Event that we only generate once indicating we're failing to generate invoices and inbound payments will fail with a useful error message. We'd only want to do it once and not on every invoice_request we receive, though.