BIP 77: Async Payjoin

bip-0077.md

@@ -183,7 +183,8 @@ Senders that understand Bitcoin URI but don't support Payjoin will just
 ignore the `pj` parameter and proceed to typical address-based
 transaction flows.
 
-A `req-pj` parameter key, as specified in BIP 21, may be used instead of
+A `req-pj` parameter may be used as a [BIP 21 forwards compatibility `reqparam`](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#forward-compatibility) instead of
+`pj` to signal that Payjoin is required.
 `pj` to signal that Payjoin is required.
 
 The parameter value must be [uppercased and the parameter should be placed last in the URI](#uppercase-url).
@@ -234,9 +235,10 @@ These session-specific parameters use a bech32-inspired encoding.
 The HRP is used as the parameter key, followed by the '1' separator,
 followed by the parameter value encoded using the bech32 character set in
 [uppercase](#uppercase-url). No checksum is used. Parameters are separated
-by a `+` character. There are no ordering requirements.
+by a `+` character.
 
-The following parameters are defined:
+The following parameters are defined, and must be provided in reverse
+lexicographical order:
 
 - `RK`: encodes the *receiver key* as a 33-byte compressed public key.
   Senders will initiate HPKE with the receiver using this key.
@@ -526,9 +528,18 @@ Unlike Bitcoin URI parameters, which require switching back to Byte
 mode, the use of the URL fragment for session-specific parameters makes
 it possible to stay in Alphanumeric mode.
 
-The `pj` parameter mailbox endpoint URL SHOULD be the last Bitcoin URI
+### Parameter Ordering
+
+The order of fragment parameters, Bitcoin URI parameters, as well as in the
+sender's optional parameters have no defined meaning.
+
+In the BIP 21 URI, the `pj` parameter mailbox endpoint URL SHOULD be the last
 parameter to avoid QR mode switching.
 
+Since variations might create a fingerprint for particular wallet software,
+this document requires that fragment parameters MUST appear in reverse
+lexicographical order.
+
 ### Session Expiration
 
 The directory may hold a message for an offline Payjoin client until that
@@ -633,7 +644,7 @@ adversary, it is desirable to do so for standard OHTTP requests as well.
 [RFC 9180 Hybrid Public Key
 Encryption](https://www.rfc-editor.org/rfc/rfc9180.html)
 (HPKE) is a modern IETF standard for secure
-message exchange without TLS, which is not available in Bitcoin Core.
+message exchange without TLS, since TLS is not available in Bitcoin Core.
 
 This proposal uses `DHKEM(Secp256k1, HKDF-SHA256)` and
 `ChaCha20Poly1305` AEAD for both OHTTP encapsulation and for end-to-end