The discussion around this proposal has led to several key considerations, currently being documented on Delving Bitcoin. A significant focus of the proposed design is metadata security, emphasizing the importance of protecting data to ensure privacy. The introduction of Oblivious HTTP (OHTTP) as a means to separate IP addresses from requests marks a notable advancement. OHTTP facilitates serverless payjoin by allowing independent server operators to run OHTTP proxies, addressing potential privacy concerns associated with Tor and VPN usage. This approach also mitigates risks related to timing attacks by OHTTP proxies through careful network protocol consideration.

Authenticated encryption in payjoin version 2 proposes a shift from relying on third-party public key infrastructures for securing interactions to a peer-to-peer model. This involves sharing ephemeral public keys between clients to authenticate and encrypt payloads specific to payjoin requests. Utilizing Hybrid Public Key Encryption (HPKE) within this framework offers simplicity and effectiveness, though it necessitates support for the secp256k1 curve used in bitcoin software. Achieving consensus on a cryptosystem that supports secp256k1 without external dependencies is seen as crucial for maintaining security and feasibility.

The choice of network transport is pivotal for ensuring broad client support and facilitating seamless integration. Exploratory work has been conducted across various transport mechanisms, including HTTP long polling and more sophisticated protocols like WebRTC and WebSockets. However, the preference leans towards using simple HTTP polling due to its widespread support, ease of implementation, and compatibility with securing IP metadata via OHTTP. This decision also aligns with objectives for backward compatibility, allowing payjoin version 2 relays to handle version 1 HTTPS ingress, despite potential UX challenges associated with keeping receivers online and the unencrypted, unauthenticated nature of version 1 payloads.

Improvements in transaction construction are introduced through PSBT version 2, which simplifies multiparty transactions and introduces new fields for carrying payjoin parameters. This development avoids reliance on additional serialization formats like JSON. The encoding of public keys in BIP21 URIs is addressed, with base64 URL encoding and blockchain commons UR encoding identified as viable options, the latter offering advantages in QR code representation.

The draft BIP and these enhancements are subject to community feedback and further discussion, with an invitation extended to software users and maintainers to contribute their views. Engagement with the community and ongoing dialogue is encouraged through resources and links provided on payjoindevkit.org.