From ef77393f72fcff7afe2a9334d3b1918d2f828529 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Wed, 10 Jul 2024 19:29:49 +0000 Subject: [PATCH] Include BIP 353 name info in `invoice_request`s MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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`. --- 12-offer-encoding.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/12-offer-encoding.md b/12-offer-encoding.md index 930d6442d..0a09ace1a 100644 --- a/12-offer-encoding.md +++ b/12-offer-encoding.md @@ -437,6 +437,12 @@ while still allowing signature validation. 1. type: 90 (`invreq_paths`) 2. data: * [`...*blinded_path`:`paths`] + 1. type: 91 (`invreq_bip_353_name`) + 2. data: + * [`u8`:`name_len`] + * [`name_len*byte`:`name`] + * [`u8`:`domain_len`] + * [`domain_len*byte`:`domain`] 1. type: 240 (`signature`) 2. data: * [`bip340sig`:`sig`] @@ -481,6 +487,10 @@ The writer: (e.g. milli-satoshis for bitcoin) for `invreq_chain` (or for bitcoin, if there is no `invreq_chain`). - if it supports bolt12 invoice request features: - MUST set `invreq_features`.`features` to the bitmap of features. + - if it received the offer from which it constructed this `invoice_request` using BIP 353 resolution: + - MUST include `invreq_bip_353_name` with, + - `name` set to the post-₿, pre-@ part of the BIP 353 HRN, + - `domain` set to the post-@ part of the BIP 353 HRN. The reader: - MUST reject the invoice request if `invreq_payer_id` or `invreq_metadata` are not present.