Skip to content

BIP 77: Delimit fragment params with - instead of + #1890

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 10, 2025

Conversation

nothingmuch
Copy link
Contributor

This PR addresses the concerns raised in #1885 with regards using + as a delimiter, by switching to -. Some URI libraries implement RFC 1866's (HTML 2.0) "keyword" delimitation in query parameters by decoding + as unconditionally, which necessitates kludgy workarounds.

Additionally fragment parameters must now ordered lexicographically (instead of reverse), the motivation for a canonical ordering was to reduce implementation fingerprinting concerns, but the reverse lexicographical ordering was specified simply because that was the behavior that was already implemented in PDK. Since that is somewhat surprising and the delimiter change breaks backwards compatibility anyway, the marginal cost in terms of compatibility of reducing the surprisingness of the reversed ordering is arguably zero, so this is also addressed here.

cc @kumulynja

@nothingmuch nothingmuch force-pushed the fragment-fixes branch 3 times, most recently from 555dff7 to cbf69f3 Compare July 8, 2025 12:54
DanGould added a commit to payjoin/rust-payjoin that referenced this pull request Jul 9, 2025
This PR contains two changes, using `-` instead of `+` as the fragment
parameter delimiter, and lexicographically ordering the fragment
parameters.

This implements bitcoin/bips#1890
Since only Bull Bitcoin Mobile and Cake wallet are currently deployed in
production, both using PDK, and the `+` character is causing some
friction, this change seems justified to avoid similar issues with
future implementations.
Copy link
Contributor

@murchandamus murchandamus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, should we wait for a review from @DanGould or is this ready to go?

Nit: We use ISO-8601 formatted dates (YYYY-MM-DD) in the preamble, so I would prefer also using the same format in the Changelog, but either is fine and this is not a blocker.

@nothingmuch
Copy link
Contributor Author

LGTM, should we wait for a review from @DanGould or is this ready to go?

I'd be more comfortable with an explicit ACK even though the corresponding code changes were merged into PDK

Nit: We use ISO-8601 formatted dates (YYYY-MM-DD) in the preamble, so I would prefer also using the same format in the Changelog, but either is fine and this is not a blocker.

ISO-8601 is better, done

@DanGould
Copy link
Contributor

ACK 1474f0d

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.
@murchandamus murchandamus merged commit 83ac842 into bitcoin:master Jul 10, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants