bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-07-21 12:58:14 +00:00
Code Issues Releases Wiki Activity

Specify lexicographical order for fragment params

Browse Source 
The rationale for this change is that since `-` instead of `+` breaks
compatibility anyway, the marginal cost of removing this
unusual/surprising requirement for reverse lexicographical ordering is
zero.
This commit is contained in:
Yuval Kogman 2025-07-03 16:25:36 +02:00
parent 43f9688600
commit 8b83c34949
1 changed files with 25 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
bip-0077.md
View File

@ -234,13 +234,14 @@ These session-specific parameters use a bech32-inspired encoding.
The HRP is used as the parameter key, followed by the '1' separator, 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 followed by the parameter value encoded using the bech32 character set in
[uppercase](#uppercase-url). No checksum is used. Parameters are separated [uppercase](#uppercase-url). No checksum is used. Parameters are separated
by a `-` character (previously a `+` separator [was specified](#bip-77)). by a `-` character.
The following parameters are defined, and must be provided in reverse The following parameters are defined, and must be provided in lexicographical
lexicographical order: order:
- `RK`: encodes the *receiver key* as a 33-byte compressed public key. - `EX`: specifies a [session
Senders will initiate HPKE with the receiver using this key. expiration](#session-expiration) in [unix
time](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16).
- `OH`: encodes an alternate format of the OHTTP Key Configuration of - `OH`: encodes an alternate format of the OHTTP Key Configuration of
the directory. It consists of a 33-byte compressed public key of the the directory. It consists of a 33-byte compressed public key of the
directory's OHTTP Gateway, prefixed by the 2-byte Key Identifier. A [ directory's OHTTP Gateway, prefixed by the 2-byte Key Identifier. A [
@ -248,12 +249,15 @@ lexicographical order:
Configuration](https://www.ietf.org/rfc/rfc9458.html#section-3.1) Configuration](https://www.ietf.org/rfc/rfc9458.html#section-3.1)
is reconstructed by assuming the HPKE KEM ID and Symmetric Algorithms is reconstructed by assuming the HPKE KEM ID and Symmetric Algorithms
are [fixed](#secp256k1-hybrid-public-key-encryption). are [fixed](#secp256k1-hybrid-public-key-encryption).
- `EX`: specifies a [session - `RK`: encodes the *receiver key* as a 33-byte compressed public key.
expiration](#session-expiration) in [unix Senders will initiate HPKE with the receiver using this key.
time](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16).
For example, a properly encoded endpoint Bitcoin URI looks like this For example, a properly encoded endpoint Bitcoin URI looks like this
`bitcoin:tb1q6q6de88mj8qkg0q5lupmpfexwnqjsr4d2gvx2p?amount=0.00666666&pjos=0&pj=HTTPS://PAYJO.IN/TXJCGKTKXLUUZ%23RK1Q0DJS3VVDXWQQTLQ8022QGXSX7ML9PHZ6EDSF6AKEWQG758JPS2EV-OH1QYPM59NK2LXXS4890SUAXXYT25Z2VAPHP0X7YEYCJXGWAG6UG9ZU6NQ-EX1WKV8CEC` `bitcoin:tb1q6q6de88mj8qkg0q5lupmpfexwnqjsr4d2gvx2p?amount=0.00666666&pjos=0&pj=HTTPS://PAYJO.IN/TXJCGKTKXLUUZ%23EX1WKV8CEC-OH1QYPM59NK2LXXS4890SUAXXYT25Z2VAPHP0X7YEYCJXGWAG6UG9ZU6NQ-RK1Q0DJS3VVDXWQQTLQ8022QGXSX7ML9PHZ6EDSF6AKEWQG758JPS2EV`
Until 2026 implementations SHOULD also accept `+` as a fragment parameter
separator and not enforce parameter ordering requirements, for compatibility
with the [previous version of this document](#changelog).
### Sender Original PSBT Messaging ### Sender Original PSBT Messaging
@ -711,8 +715,6 @@ receiver also specifies the directory.
## Backwards compatibility ## Backwards compatibility
### BIP 78
Senders not supporting Payjoin will just ignore the `pj` parameter and Senders not supporting Payjoin will just ignore the `pj` parameter and
proceed to typical address-based transaction flows. proceed to typical address-based transaction flows.
@ -728,18 +730,6 @@ seconds or else the directory should respond with an `unavailable` JSON
error code as [defined in BIP error code as [defined in BIP
78](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-well-known-errors). 78](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-well-known-errors).
### BIP 77
A previous version of this document specified `+` as the fragment parameter
separator. This can cause issues due to a common convention (not specified in
RFC 3986, but in RFC 1866 in relation to HTML form submission and query
parameters, not URI fragments) of representing ` ` with `+` in URI query
parameters.
As a result of this change implementations are encouraged to still accept `+`
delimited fragment parameters for during 2026 (a grace period of just under 6
months).
## Reference implementation ## Reference implementation
A production reference implementation client can be found at A production reference implementation client can be found at
@ -748,3 +738,15 @@ directory, and development kit may be found here:
<https://github.com/payjoin/rust-payjoin>. Source code for an Oblivious <https://github.com/payjoin/rust-payjoin>. Source code for an Oblivious
HTTP relay implementation may be found here: HTTP relay implementation may be found here:
<https://github.com/payjoin/ohttp-relay>. <https://github.com/payjoin/ohttp-relay>.
## Changelog
- 0.2.0 2025-07-08
- Change fragment parameter delimiter from `+` to `-` to improve
compatibility with generic URI parsing libraries, and order them
lexicographically. `+` can cause issues due to a common convention (not
specified in RFC 3986, but in RFC 1866, in relation to HTML form
submission and query parameters) of interpreting `+` as ` ` when decoding
URIs.
- 0.1.0 2025-05-28
- First merged Draft version of BIP 77