As Bitcoin has grown, the introduction of new address formats
describing new forms of payment instructions has become
increasingly fraught with compatibility issues. Not only does there
exist traditional on-chain addresses, but some recipients wish to
receive Lightning (when the sender supports it) or newer formats
such as Silent Payments.
This has led to increasing use of the BIP 21 query parameters to
encode further optional payment instructions.
Looking forward, as new payment instructions get adopted, it makes
much more sense to include them in query parameters rather than
replace the existing address field, ensuring compatibility with
senders and recipients who may or may not be upgraded to support
all the latest payment instructions.
This updates BIP 321 to suggest that future address formats do this.
Further, it updates BIP 321 to allow an empty bitcoin address in
cases where new payment instructions have moved to becoming
mandatory. This isn't a backwards-incompatible change any more than
switching to a new address format is, so doesn't impact existing
BIP 21 implementations in a new way, however provides a nice
conclusion to the query-parameter-based upgrade path - once a form
of payment instructions has broad adoption, senders can simply drop
the existing address field, keeping their existing query parameter
encoding, rather than replace the existing address field. It also
addresses the question of what to do if a wallet no longer wishes
to receive some legacy on-chain address, but has multiple payment
instruction formats that they wish to include - deciding which one
to place in the address field would be a difficult task.
Finally, it defines a new query parameter, the `pop` parameter,
which allows the initiating application to receive callbacks for
proof of payment completion.
If someone puts a lightning BOLT 12 offer in a BIP 353 entry with
the offer expiring before the DNS entry's TTL (plus now), they may
get stuck being unpayable, so its worth explicitly mentioning that
people should take care here.
When using BIP 353 for on-chain addresses (incl silent payments),
it is useful to be able to include DNSSEC proof information in
outputs of a PSBT, which we enable here by defining a standard
field for it.
It seems confusing to call BIP 353 names "addresses", and most of
the BIP refers to them as "names", but a few "human-readable
addresses" snuck in in a recent change, which are fixed here.
User behavior has clearly indicated a strong demand for the
resolution of human-readable names into payment instructions. This
BIP defines a protocol to do so using only the DNS, providing for
the ability to query such resolutions privately, while utilizing
DNSSEC to provide compact and simple to verify proofs of mappings.
Matt Corallo