-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
BIP 77: Payjoin Version 2 — Async Payjoin #1483
base: master
Are you sure you want to change the base?
Conversation
Let's call this BIP 77 |
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. |
Since the last review I have made breaking changes, which I'll apply with an update now. I think we're at the point where each design decision I'm aware of is deliberate. I'll take it out of draft once the new update is pushed. |
The main changes from the last review are that
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NACK
This BIP is bad for privacy and lacks details in "attack vectors" section. Please be careful while implementing.
Can you provide the reasoning, please? |
Risks with accepting donations using payjoin:
|
Example: https://hrf.org/payjoin |
@1440000bytes Your first point has already been addressed and he has added a link to the attack vectors section on BIP-78. No one is "not accepting" anything. Are you asking that the full explanation given on probing attacks in BIP-78 be redundantly added here? What exactly is your criticism? Your second point has already been addressed in BIP-78, here is what the link that you suggested be added says:
BIP-78 already explains what can be done to mitigate this, and fully acknowledges this tradeoff. |
The sender could first register an additional session subdirectory for the response, and include the associated public key along with the original PSBT when posting to the receiver's subdirectory. The sender would then respond in the sender's subdirectory. Eliminating the request/response distinction would avoid a metadata leak, namely whether or not the payjoin flow was completed, since requests and responses would be indistinguishable. A followup suggestion would be removing explicit session initialization. Incidentally in the reference directory it appears that since Timing analysis of subdirectory polling could still leak information about which payjoin requests were responded to, but aggressive clients could mitigate this by maintaining a pool of pre-allocated and randomly polled subdirectories ahead of time, and by responding to themselves in some of them with dummy payloads to generate random cover traffic. |
@nothingmuch I'll write up your suggestions to simplify the protocol. It makes the directory implementation simpler, requires fewer protocol message types, and even reduces bandwidth. wowza
HPKE E2EE deployed in this application in Authenticated mode (akin to Noise Framework's IK model) already requires the sender to include their session public key as associated data, so this is an pretty darn easy change to make. The change not only simplifies the protocol messaging, but as you say eliminates a metadata leak. I'm a big fan.
This makes sense too. Creating separate subdirectory resources for either sender or receiver on POST then GETting updates to replace the repeated sender POST polling reduces bandwidth too, since the GET request doesn't contain that repeat POST body. Even without aggressive client mitigation of the remaining client leaks subject to timing analysis assuming this suggestion is put in place, your new design deletes complexity and improves efficiency. I'll update the BIP to the best of my understanding based on your comment and link it to a Edit: Is there a potential authorization issue now that the sender POSTs first? In the current design of the protocol, only the receiver might need authorization from the directory in order to initialize a session subdirectory, and having knowledge of a session public key was sufficient for the sender to use an initialized subdirectory. Now, the sender would also need to obtain authorization somehow, since the directory doesn't yet know about the session the receiver has implicitly initiated by communicating directly with the sender, out of band from the directory. We'll have to work out how this might affect the expiration mechanic as well. |
The specifics of a credential issuance are left out, however
Co-authored-by: Yuval Kogman <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor clarifications following the "original"/"proposal" payjoin PSBT terminology established in BIP78.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I struggled a bit to grok the new messaging flow. After reading through the implementation I think I get it now and left some corrections/clarification suggestions throughout.
Co-authored-by: spacebear <[email protected]>
===Receiver's Proposal PSBT checklist=== | ||
|
||
The receiver checklist is the same as the [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-original-psbt-checklist| the BIP 78 receiver checklist]], except for the "Verify that the payjoin proposal did not introduce mixed input's type" step, which may be ignored. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
===Receiver's Proposal PSBT checklist=== | |
The receiver checklist is the same as the [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-original-psbt-checklist| the BIP 78 receiver checklist]], except for the "Verify that the payjoin proposal did not introduce mixed input's type" step, which may be ignored. | |
===Receiver's Original PSBT checklist=== | |
The receiver checklist is the same as the [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-original-psbt-checklist| the BIP 78 receiver checklist]], except for the "If the sender's inputs are all from the same scriptPubKey type, the receiver must match the same type" step, which may be ignored. |
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.