Drop the extra round-trip and use lno, not b12.

blip-0032.md

@@ -83,8 +83,8 @@ payment instructions. A current draft may be found at
 Secondly, this document describes a method of fetching DNSSEC proofs without exiting the lightning
 network.
 
-Finally, the BOLTs define onion messages containing `offer_request`s or `offer_response`s to lookup
-offers over onion messages.
+Finally, a forthcoming bLIP will define a method to include the `user` part of the human-readable
+name used to look up an `offer` in the `invoice_request`.
 
 #### Payer Protocol
 
@@ -100,26 +100,23 @@ Upon receipt of the responding `dnssec_proof` the payer validates the `proof` ag
 root trust anchor and if it passes parses any TXT records which
 `user`.user._bitcoin-payment.`domain` resolves to as a `bitcoin:` URI.
 
-From there, a lightning payer will search for (case-insensitive) `b12` or `omlookup` query
-parameters in the resulting URI. If it finds a `b12` query parameter, its value should contain a
-full offer, which the payer can simply pay.
+From there, a lightning payer will search for (case-insensitive) the `lno` query parameter in the
+resulting URI. If it finds an `lno` query parameter, its value should contain a full offer, which
+the payer can simply pay.
 
-If the payer identifies an `omlookup` query parameter in the resolved URI instead, it will send an
-`offer_request`-containing onion message to the blinded path provided in the `omlookup` query
-parameter value. Upon receiving the `offer_response`-containing onion message response, the payer
-will have a BOLT12 offer which they can pay as normal.
+In order to allow for a static offer receiving funds on behalf of many users, the payer should
+include the `user` from their original query in the `invoice_request` they send the recipient.
 
 #### Recipient Configuration
 
 Recipient configuration is quite straightforward. For a recipient owning their own domain with a
 personal offer, they simply add a TXT record at `user`.user._bitcoin-payment.`domain` with the
-contents `bitcoin:?b12=OFFER`.
+contents `bitcoin:?lno=OFFER`.
 
 Alternatively, for recipients which do not wish to publish a unique offer for all possible payees,
-a wildcard record may be provisioned as *.user._bitcoin-payment.`domain` with the contents
-`bitcoin:?omlookup=hex_encoded_blinded_path`. The node receiving onion messages at the given
-blinded path is then expected to respond to `offer_request`-containing onion messages with
-`offer_response`-containing onion messages.
+a wildcard record may be provisioned as *.user._bitcoin-payment.`domain` with the same contents.
+The node receiving the `invoice_request` can use the `user` field to determine for which user the
+payment is intended and generate an `invoice` specific to that `user`.
 
 ## Reference Implementation
 * LDK-based resolver: <https://git.bitcoin.ninja/index.cgi?p=lightning-resolver;a=summary>