bLIP: BOLT 11 Invoice Blinded Path Tagged Field

[t-bast]

@roasbeef

As it’s just a bLIP, so implementations are free to take it or leave it.

Sure, as a bLIP it’s completely acceptable, I’m just saying that I don’t think we would implement this bLIP in eclair or lightning-kmp.

@roasbeef

When presented with an encoded Offer, what does Phoenix/Eclair do today?

It’s exactly the same as being presented with an encoded invoice: once you scan it, you then go through the same payment UI where you may enter an amount, and additionally a small note for the recipient, and then the payment simply happens (with invoice fetching before going through path-finding). I think users don’t need to know that an invoice is being fetched as the first step of the protocol.

@roasbeef

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?

In the long term where all senders support Bolt 12, as a wallet you would only use offers to receive payments, and would use the DNS address format: no QR codes shown anymore, just the “identifier” of the recipient. This is a much better UX than the current QR code flow.

We would keep support though for paying Bolt 11 invoices, as there may be online merchant use-cases that require it, and it wouldn’t need any code change.

@roasbeef

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.

That’s true