Include BIP 353 name info in invoice_requests

[TheBlueMatt]

Based on #798,

BIP 353 defines a method for resolving Human Readable Names (in the
form ₿`name`@`domain`) into bitcoin: URIs. In order to use them with
BOLT 12 with a wildcard DNS entry which resolves to a single
BOLT 12 offer for all `name`s in a domain, we need a way to
disambiguate the `name` being paid in an `invoice_request` which we
provide here by simply copying the HRN into the `invoice_request`.

[t-bast]

Thanks for sharing this. I'm not sure how the node receiving an invoice_request containing a BIP 353 address should behave though. It shouldn't be specified here (probably rather in a bLIP), but it's useful to have the high-level design discussed here to help reviewers.

Let's assume that Bob is the domain owner and Alice the end user (₿alice@bob.com). Carol is trying to pay Alice: she resolves *@bob.com, receives an offer created by Bob, and sends an invoice_request containing ₿alice@bob.com to Bob.

What does Bob do with this invoice_request, which contains its own offer instead of an offer generated by Alice? It cannot simply forward it to Alice, because Alice won't issue an invoice for an offer owned by Bob?

Does Bob instead reply to Carol with an offer from Alice and Carol then follows up with another invoice_request for that offer? Or is there a mechanism on Alice's side to create an invoice for her own offer, even though it doesn't match Carol's invoice_request (and thus also a mechanism for Carol to accept the returned invoice)?

[TheBlueMatt]

I'm not sure how the node receiving an invoice_request containing a BIP 353 address should behave though.
Let's assume that Bob is the domain owner and Alice the end user

Obviously this isn't an issue for custodial services, so I assume you're asking about non-custodial. In this case Bob would have to issue an invoice using a payment_hash and blinded path from Alice. This would require some proprietary (bLIP?) protocol where Bob can ask Alice for a fresh payment_hash and blinded path (replacing the final onion message hop, so its no new latency).

For async payments its a bit more complicated, but Alice can simply register her payment parameters with Bob rather than a full static invoice, which Bob can turn into his own static async invoice for Alice.

Its a chunk of additional protocol work to implement, so IMO people should just put a few 100k DNS entries in a zone (which is super trivial, just dont use some hosted DNS garbage that charges you $$$$$ to store 5MiB of data), but someone could build this if they want. I think this will likely be used much more for custodial services where its trivial.

It shouldn't be specified here (probably rather in a bLIP)

Why? You could reasonably argue that many wallets won't implement BIP 353 sending and thus it should be a bLIP, but it seems like all of the major lightning implementations will need to support this field (as at least some of their users will implement BIP 353 sending), which implies it should be here.

[t-bast]

In this case Bob would have to issue an invoice using a payment_hash and blinded path from Alice. This would require some proprietary (bLIP?) protocol where Bob can ask Alice for a fresh payment_hash and blinded path (replacing the final onion message hop, so its no new latency).

That means Alice will create an invoice for an offer created by Bob, not her own offer...I'm not sure how messy it will be to implement: since Alice doesn't have the private key for Bob's offer, she can't sign that invoice. So that's probably the wrong approach, and you're instead proposing that Bob is creating and signing the invoice, but the blinded path leads to Alice? So when receiving the payment, Alice just needs to be ok with the fact that the offer wasn't generated by her.

The issue with that scheme is that it's not TOFU: for every payment, Bob has an opportunity to cheat and generate invoices that are actually for him. Wouldn't it be a better idea to use the DNS resolution to (somehow) obtain an offer from Alice? This would be TOFU, but then the offer can be verified IRL, and afterwards the payer is guaranteed that they'll keep paying Alice whenever they reuse this offer. This way payers store the offer they received, and don't need to make DNS requests the next time they want to pay Alice.

so IMO people should just put a few 100k DNS entries in a zone

That is indeed my preferred option as well, this is a simpler flow!

Why? You could reasonably argue that many wallets won't implement BIP 353 sending and thus it should be a bLIP, but it seems like all of the major lightning implementations will need to support this field (as at least some of their users will implement BIP 353 sending), which implies it should be here.

I wasn't saying that this PR shouldn't be in the BOLT, but rather that the additional protocol we're mentioning should be a bLIP. I agree that this BIP 353 field in invoice_requests should probably be in the BOLTs once we've sketched out how to use it properly.

[TheBlueMatt]

That means Alice will create an invoice for an offer created by Bob, not her own offer...I'm not sure how messy it will be to implement: since Alice doesn't have the private key for Bob's offer, she can't sign that invoice. So that's probably the wrong approach, and you're instead proposing that Bob is creating and signing the invoice, but the blinded path leads to Alice? So when receiving the payment, Alice just needs to be ok with the fact that the offer wasn't generated by her.

Right, I think we're on the same page. Having Alice create the offer is probably a non-starter. Luckily if Alice builds the blinded path she doesn't know that she didn't create the offer. She just sees the blinded path she generated in an HTLC :)

The issue with that scheme is that it's not TOFU: for every payment, Bob has an opportunity to cheat and generate invoices that are actually for him. Wouldn't it be a better idea to use the DNS resolution to (somehow) obtain an offer from Alice?

Yea, I agree, you could have some scheme where you fetch an offer instead (which is how the original bLIP was specified), but I wanted to avoid the extra round-trip during normal payment flows. Sadly, BIP 353 is somewhat limited in TOFU-ness as you do need to revalidate the DNS records occasionally (often on the order of a day, depending on DNS settings, both to let people rotate addresses if they want but also to make sure the domain hasn't expired). A wallet can (and maybe should) of course warn the sender if the recipient info has changed, but its never perfect TOFU.

This would be TOFU, but then the offer can be verified IRL, and afterwards the payer is guaranteed that they'll keep paying Alice whenever they reuse this offer. This way payers store the offer they received, and don't need to make DNS requests the next time they want to pay Alice.

If you're able to "verify IRL" you shouldn't be using BIP 353 :).

I wasn't saying that this PR shouldn't be in the BOLT, but rather that the additional protocol we're mentioning should be a bLIP. I agree that this BIP 353 field in invoice_requests should probably be in the BOLTs once we've sketched out how to use it properly.

Ah, okay! I have no intention of specifying that protocol. If people want to offer BIP 353 names for non-custodial wallets they'll have to either build it or just deal with running BIND/KNOT/etc themselves 🤷‍♂️.

[t-bast]

Thanks, that's clear enough! I agree on all points 👍

[TheBlueMatt]

Rebased now that BOLT 12 landed 🎉. This should be good to go.

[ariard]

#1136 (comment)

[t-bast]

LGTM 👍

[t-bast]

LGTM 👍

[Roasbeef]

LGTM 👑

pending @rustyrussell's encoding comments

[TheBlueMatt]

Update to describe allowed list of characters for @rustyrussell.

[t-bast]

ACK 89b99a5

[rustyrussell]

Ack!