bLIP: BOLT 11 Invoice Blinded Path Tagged Field

[roasbeef]

@t-bast

but if I had to choose between adding blinded paths to Bolt 11 invoices or exposing Bolt 12 invoice, I’d rather expose Bolt 12 invoices. This requires less code and less additional spec work.

IIUC, we would still need spec modifications, in order to allow fields that are currently considered mandatory (fields referencing the offer ID, etc) to now be optional. Most of the text above is also an Appendix re how to estimate the size of the BOLT11 invoice with blinded paths, which would still be needed for BOLT 12 invoice.

@t-bast

To be honest, I don’t think we should waste time with such intermediate steps (that will need to be maintained for a long time, create technical debt and confusion for users). I find it more useful to focus that time on shipping Bolt 12 code, but that’s just my opinion.

As it’s just a bLIP, so implementations are free to take it or leave it. IMO long term, this helps to make the whole Offers flow more robust, as we’re able to get more experience with blinded paths, find edge cases, implement the new path finding from the receiver, etc, etc. Personally, I prefer to work a small component, and refine that as much as possible before moving onto the next. Otherwise you have all these components which are only partially refined, which may actually extend the full deployment timeline.

@t-bast

I don’t think this is very useful…I don’t believe this will prompt users to ask wallet developers to implement stuff, and the only result of that is a bad UX where users scan a QR code and they’re told it doesn’t work.

When presented with an encoded Offer, what does Phoenix/Eclair do today? Does it let the user know that it’s about to try to fetch the offer (retries, fallback, etc) and ask for confirmation, or does it just go ahead in the background with some loading UI? Or is it always direct connect?

Also in terms of the ultimate switch over to Offers for everything, won’t wallet developers still need to gracefully handle being presented with either a BOLT11 invoice or an Offer? What’s the latest thinking here re UX?

FWIW, AMP invoice also exist in the wild, and wallets seem to be able to handle detecting if they can or cannot pay it.

@t-bast

I haven’t looked at the details in a while, but at a high-level it seems to me that L402 would benefit a lot from using offers rather than hacking blinded paths on top of Bolt 11 invoices? That requires more work to upgrade L402, but I’m a strong believer that doing short-term intermediate “hacks” is always a waste of time in the long term because of the maintenance cost.

So L402 is itself an invoice negotiation protocol, the client hits the endpoint, gets the L402 along with the invoice, then pays it. Therefore, Offers doesn’t have much of a role here, as we get an invoice in the HTTP response from the server. This invoice can ofc use blinded paths.

---

With all that said, I don’t consider this a hack, as it’s using an existing extension vector in an existing invoice format. This can also be applied to the new invoice format as well. The bulk of the logic and code comes after/before (path finding, blinded hop construction and processing, etc) the invoice is encoded in the first place. Blinded paths itself is also primarily the concern of the onion/routing layer, the encoding/presentation layer is independent of the core component. The fact that people tend to bundle it in their minds with Offers is primarily due to opinionated protocol packaging.