BIP 77: Payjoin Version 2 — Async Payjoin #1483
Conversation
|
Let's call this BIP 77 |
luke-jr
changed the title
|
Hi @DanGould, the first comment on this PR seems to indicate that this proposal is still WIP. Is that an accurate understanding? If this PR is not yet ready to be merged, perhaps it should be changed to "Draft". If I misunderstood the status of this PR, please respond below so someone may review to assess whether this is ready for merge. |
This is the most straightforward way to explain the various padding requirements.
Enable opt-in Gateway reachability for BIP 77 The [BIP 77 Draft](bitcoin/bips#1483) imagines clients reach one another over a "mailbox" store-and-forward server through OHTTP Relays. In order for Relays to reach those mailbox servers without being pre-defined, this release includes support for an opt-in mechanism based on RFC 9540's Oblivious Gateway discovery mechanism augmented with an `allowed_purposes` parameter that may specify the BIP 77 mailbox as a specific service. This was activated by implementing probing functionality that caches `allowed_purposes` responses to prevent this Relay from being party to denial of service attacks where a client might spam requests to Gateways that do not support an allowed purpose.
|
Would be great to move this draft forward. Relevant blog post and discussion yesterday: |
There was a problem hiding this comment.
Thank you for updating the line breaking.
I was trying to the determine the status of this proposal. It looks like many of the review comments (now marked "Outdated" due to the reformatting) have not been processed, yet, so it seems to me that it is still in the Author’s court and I leave the "PR Author action required" label.
When you do process the review, please mark the processed comments as resolved or reply to them to indicate the same if you have additional information to share with reviewers.
MUST NOT contained MUST details. Move them to MUST.
bip-0077.mediawiki
Outdated
| compromising sender or receiver privacy. | ||
|
|
||
| Although unsecured Payjoin server separation is mentioned in BIP 78, no known specification or implementation | ||
| exists. This document specifies a way to use the Payjoin directory as an unsecured backwards compatible server |
There was a problem hiding this comment.
There are alternately references to "Payjoin directory", "Payjoin Directory", and "payjoin directory" right now. Does a Payjoin Directory technically qualify as a proper noun? Same question for OHTTP relay vs. OHTTP Relay, since it is a specific type of relay.
Whichever the choice, I think this should be consistent
Last updates here were 3 months ago, if I'm not misreading. Pinging BIP author @DanGould. |
|
@nothingmuch and I have been revising behind the scenes over the past 2 weeks. Have not forgotten. Update coming soon |
This document proposes an asynchronous, backwards-compatible second version of the payjoin protocol described in BIP 78, enabling complete payjoin receiver functionality including payment output substitution with only an HTTP client rather than server. The former requirement for receivers to run HTTP servers is replaced with an untrusted third-party "payjoin directory" store-and-forward server accessed by polling clients which communicate using an asynchronous protocol and authenticated, encrypted payloads. It was originally proposed to the mailing list here.
The protocol design has received rounds of review elsewhere on the bitcoin-dev mailing list as well.
Feedback from that list post has been incorporated into this draft.
Proposing this as an Standards Track BIP to ensure wallets across the ecosystem can come to rough consensus on a single asynchronous payjoin standard and correctly implement it widely.