This BIP is licensed under the 2-clause BSD license.
\nPayjoin lets Bitcoin senders and receivers interact to make batched\ntransactions.
\nThis document proposes a second, backwards-compatible, asynchronous version of\nthe Payjoin protocol ("Version 2") relative to and described in BIP 78 ("Version 1"). An untrusted\nthird-party "directory server" replaces the requirement\nfor a receiver to host a secure public endpoint for interactions. HTTP clients\naccess the directory server using an asynchronous protocol and authenticated,\nencrypted payloads. The design preserves complete Payjoin receiver\nfunctionality, including payment\noutput substitution. Authenticated encryption depends only on cryptographic\nprimitives available in Bitcoin Core. Requests use Oblivious\nHTTP (OHTTP) to\nprevent the directory and other Payjoin clients from linking requests to client\nIP addresses.
\nSatoshi Nakamoto pointed out one specific privacy risk in the\nwhitepaper,\nthat transactions with multiple inputs "necessarily reveal that\ntheir inputs were owned by the same owner."\nPayjoin addresses that risk, the common-input-ownership heuristic,\nby making it practical to spend inputs owned by multiple parties\nin one transaction.
\nWhile addressing Bitcoin's primal privacy risk, Payjoin input batching\nalso improves on the widespread non-interactive output batching practice\ndeployed by exchanges. When combined, the same movement of funds can use\nless block weight and save fees.
\nA natural application of Payjoin would be to combine\ngetting paid with consolidating UTXOs into one transaction. But Payjoin\ncan also secure transaction\ncut-through,\nallowing a sender to transfer funds to a receiver who also transfers\nfunds to a third party in the same transaction. For example, deposits to an\nexchange may "cut through" in a single transaction that also satisfies\nwithdrawals instead of with a second transaction that spends the deposited\nfunds. Payjoin enables more blockspace-efficient transactions that\nreduce fees while addressing privacy risks.
\nHowever, BIP 78's requirements for Payjoin Version 1 have proven to be an\nobstacle to adoption. Version 1 receivers must host a secured\npublic-facing HTTP server. Mobile and web environments limit the ability\nto fulfil such a requirement. Version 1 also requires synchronous\ncommunication. Both sender and receiver must be online simultaneously.\nWallet developers \nregard\nthese requirements as barriers to Payjoin adoption.
\nTo address these limitations, our goal is to specify a practical\ncoordination mechanism suitable for widespread implementation. This proposal\nleverages mature solutions to common problems, building on established web\nstandards and proven Bitcoin primitives.
\nA Payjoin sender and receiver interact so that they may both contribute to a\ntransaction. In this proposal, they exchange asynchronous end-to-end\nencrypted messages by relaying them to a store-and-forward directory server\nusing OHTTP.
\nBefore initiating the protocol, the receiver must secure communications with\nthe directory by bootstrapping.
\nAt any point, either party may choose to broadcast the\nfallback transaction described by the Original PSBT instead of proceeding.\nBecause the Original PSBT and Proposal PSBT spend the same input(s) they are\nmutually exclusive and only one can be confirmed.
\nMessages are buffered in the directory, allowing both parties to tolerate\ntemporary disconnections and resume communication by polling.
\n +----------+ +------------+ +----------+ +----------+\n | Receiver | | Directory | | Sender | | Network |\n +----+-----+ +-----+------+ +----+-----+ +----+-----+\n | | | |\n | Payjoin URI (BIP21), out-of-band | |\n +------------------------------------------------>| |\n | | | |\n | Poll GET: original PSBT (repeat until available) |\n +- - - - - - - - - - - ->+ | |\n | # POST: original PSBT | |\n | #<-----------------------+ |\n | 200 OK: original PSBT # | |\n |<-----------------------+ | |\n | | | |\n | | Poll GET: proposal PSBT (repeat until available)\n | +<- - - - - - - - - - - -+ |\n | POST: proposal PSBT # | |\n +-----------------------># | |\n | # 200 OK: proposal PSBT | |\n | +----------------------->| |\n | | | |\n | | | Broadcast payjoin |\n | | +---------------------->|\n | | | |\nBefore initiating a Payjoin Session a receiver must first discover the\ndirectory's\nOHTTP Key Configuration,\nvia an authenticated\nbootstrap mechanism. The key configuration contains information to establish\nHybrid Public Key Encryption (HPKE) in order to secure communications between the client and the directory in\nlieu of TLS.
\nThe bootstrap mechanism may vary by implementation but must\nfollow OHTTP Consistency\nRequirements\nand should not reveal a receiver IP address to the directory. Some\nexamples of suitable mechanisms include getting a key configuration\nfrom a Payjoin URI, a trusted application binary, or fetching using https-in-http\nCONNECT method, https-in-WebSocket, Tor, or a VPN.
\nDirectory OHTTP Gateways MUST support RFC 9540 Key Configuration\nFetching\nvia GET request. RFC 9540 defines the\ngateway location as /.well-known/ohttp-gateway.
A receiver initiates a session by sharing a Payjoin URI. Because a URI\ncontains sensitive information, such as a receiver address, it should be shared\nover a confidential channel.
\nBitcoin URIs (BIP\n21\nor BIP\n321)\nare a standard way to request bitcoin.
\nA Payjoin URI is a Bitcoin URI that contains a pj parameter. The pj\nparameter value is a URL in both BIP 78 and BIP 77.
Senders that understand Bitcoin URI but don't support Payjoin will just\nignore the pj parameter and proceed to typical address-based\ntransaction flows.
A req-pj parameter may be used as a BIP 21 forwards compatibility reqparam instead of\npj to signal that Payjoin is required.
The parameter value must be uppercased and the parameter should be placed last in the URI.
\nSince BIP 78 payloads are neither encrypted nor authenticated,\na directory used for backwards-compatible payloads is known\nas an "unsecured payjoin server" in BIP 78\nparlance.\nBackwards-compatible receivers MUST disable output substitution\nby setting pjos=0 to prevent modification by a malicious directory.
In this proposal the URL in the pj parameter value is the mailbox\nendpoint URL. Mailboxes are shared HTTP resources hosted by the\ndirectory and serve as OHTTP Target Resources. Clients use these endpoints\nto relay encrypted messages. They POST messages to and GET messages from\nmailbox endpoints via OHTTP.
Senders that support BIP 78 but not this proposal may POST messages directly to\nmailbox endpoints for backwards compatibility.
\nA Short ID identifies a mailbox based on its associated public key. The Short\nID is the path component of the mailbox endpoint. One is derived by hashing the\n33-byte compressed public key encoding with SHA-256, truncating it to\n8 bytes (64 bits), and encoding it in\nuppercase using the bech32 character set (like a bech32 string without the HRP, separator and checksum).
\nThis proposal introduces session-specific parameters which the\nreceiver shares encoded in the URI.
\nInstead of defining new Bitcoin URI parameters, the session-specific\nparameters are encoded in the \nfragment\nof the mailbox endpoint URL.
\nThe # fragment separator character must be RFC 3986\npercent-encoded\nas %23, because it separates the\nfragment of the mailbox endpoint URL included in the pj parameter, not the\nfragment of the Bitcoin URI.
These session-specific parameters use a bech32-inspired encoding.\nThe HRP is used as the parameter key, followed by the '1' separator,\nfollowed by the parameter value encoded using the bech32 character set in\nuppercase. No checksum is used. Parameters are separated\nby a - character.
The following parameters are defined, and must be provided in lexicographical\norder:
\nEX: specifies a session\nexpiration in unix\ntime.OH: encodes an alternate format of the OHTTP Key Configuration of\nthe directory. It consists of a 33-byte compressed public key of the\ndirectory's OHTTP Gateway, prefixed by the 2-byte Key Identifier. A \nRFC 9458 Key\nConfiguration\nis reconstructed by assuming the HPKE KEM ID and Symmetric Algorithms\nare fixed.RK: encodes the receiver key as a 33-byte compressed public key.\nSenders will initiate HPKE with the receiver using this key.For example, a properly encoded endpoint Bitcoin URI looks like this\nbitcoin:tb1q6q6de88mj8qkg0q5lupmpfexwnqjsr4d2gvx2p?amount=0.00666666&pjos=0&pj=HTTPS://PAYJO.IN/TXJCGKTKXLUUZ%23EX1WKV8CEC-OH1QYPM59NK2LXXS4890SUAXXYT25Z2VAPHP0X7YEYCJXGWAG6UG9ZU6NQ-RK1Q0DJS3VVDXWQQTLQ8022QGXSX7ML9PHZ6EDSF6AKEWQG758JPS2EV
Until 2026 implementations SHOULD also accept + as a fragment parameter\nseparator and not enforce parameter ordering requirements, for compatibility\nwith the previous version of this document.
The sender constructs the fallback transaction, a typical transaction\nspending funds to the receiver's address specified in the Payjoin URI.\nThis transaction is serialized as a BIP 174 PSBTv0, satisfying\nthe receiver checklist.
\nThe Original PSBT MUST:
\nThe Original PSBT MAY:
\nThis Original PSBT is encoded as base64, followed by the query\nparameter string on a new line containing optional sender\nparameters.
\nThe sender generates an ephemeral mailbox key. The corresponding public key is\nknown as the reply key, and it is prepended to the base64 plaintext string,\nserialized in compressed form as 33 bytes.
\nThis plaintext string is encrypted to the receiver key according to HPKE Base\nmode.\nThe HPKE info string, used for domain separation, is PjV2MsgA. The\nciphertext ensures message secrecy and integrity when passed to the receiver\nusing the mailbox endpoint. The 16-byte authentication tag is appended to the\nciphertext.
RFC 9180 does not\nspecify the wire format\nencoding of HPKE messages. To construct an HPKE payload, the secp256k1 public\nkey from the DHKEM is encoded using ElligatorSwift in 64 bytes. Note that\nElligatorSwift is only the wire format; when deriving shared secrets, the curve\npoint is re-serialized in uncompressed form.
\nPjV2MsgA Byte Representation (7168 bytes total)\n+---------------------------------------------------------------------------------------+\n| ElligatorSwift | Ciphertext |\n| (64 bytes) | (7104 bytes) |\n| +-----------------------+---------------------------------+------------+\n| | Reply Key | Padded Plaintext | AEAD Tag |\n| | (33 bytes) | (7055 bytes = 7168-64-33-16) | (16 bytes) |\n+---------------------------------------------------------------------------------------+\nThe resulting HPKE payload is the body of a POST request to the\nreceiver's mailbox. This request is then \nencapsulated according to\nOblivious HTTP to the directory's OHTTP Gateway. OHTTP serializes the\ninner request as BHTTP, and provides another layer of HPKE encryption,\nbetween the client and directory.
\nUpon receipt, the directory's OHTTP Gateway decapsulates the OHTTP\nrequest and handles the inner POST request at the receiver's mailbox\nendpoint, which stores the HPKE encrypted payload to be forwarded to the\nreceiver.
\nThe sender then polls OHTTP encapsulated GET requests to the sender's\nmailbox endpoint until it receives a response from the directory\ncontaining the receiver's Proposal PSBT, and proceeds to\nsign and broadcast.\nIt stops polling after expiration.
\nBIP 78's optional sender parameters\nmay be used in this proposal, but must be included in\nthe body as part of the ciphertext rather than as a query string.
\nHPKE binds ciphertexts to application-specific info strings. Because\nof this domain separation, BIP 78's v parameter is redundant and\nshould be omitted for this proposal.
After sharing the Payjoin URI with the sender, the receiver polls via\nOHTTP encapsulated GET requests to the receiver's mailbox endpoint. So\nlong as the mailbox contains no message, the directory responds with\nstatus 202 ACCEPTED. Once a mailbox contains a message, the directory\nreturns it in the response body with status 200 OK.
\nUpon receiving an encapsulated 200 OK response, the receiver decrypts\nthe payload and checks the Original PSBT therein according to the\nreceiver checklist.
\nThe receiver then updates the Original PSBT to include new signed\ninputs and outputs, invalidating the sender's signature(s). The receiver\nmay also adjust the transaction fee. The result, called the Proposal\nPSBT, must satisfy the sender checklist
\nThe Proposal PSBT MUST:
\nThe Proposal PSBT sender MAY:
\nThe Proposal PSBT MUST NOT:
\nThe receiver encrypts the Proposal PSBT to the sender's reply key according to\nHPKE Auth\nmode,\nusing the receiver's key for authentication. The HPKE info string is\nPjV2MsgB. The HPKE wire format is the same as in the sender's\nmessage.
PjV2MsgB Byte Representation (7168 bytes total)\n+---------------------------------------------------------------------------------------+\n| ElligatorSwift | Ciphertext |\n| (64 bytes) | (7104 bytes) |\n| +---------------------------------------------------------+------------+\n| | Padded Plaintext | AEAD Tag |\n| | (7088 bytes = 7168-64-16) | (16 bytes) |\n+---------------------------------------------------------------------------------------+\nThe receiver makes the resulting HPKE payload the body of a POST request to the\nsender's mailbox whose Short ID is derived from the sender's reply key. This request is then \nencapsulated according to\nOblivious HTTP to the directory's OHTTP Gateway. OHTTP serializes the\ninner request as BHTTP, and provides another layer of HPKE encryption,\nbetween the client and directory.
\nThe above describes the receiver's reply path when the sender used\nVersion 2. When the sender used the BIP 78 backwards-compatible path\n(the Original PSBT was a BIP 78 cleartext payload rather than an\nHPKE-encrypted v2 message), the receiver's response MUST instead follow\nBackwards compatibility: the Proposal PSBT\nis not HPKE-encrypted and the request method is PUT.
Once the receiver makes this request, they wait for either transaction from the\nOriginal PSBT or Proposal PSBT to be broadcast to the Bitcoin network.
\nThe receiver checklist is the same as the BIP 78 receiver\nchecklist.
\nThe sender validates the Proposal PSBT it receives against a\nchecklist. If the checks pass, it may sign and broadcast the resulting\nPayjoin transaction.
\nThis proposal's sender checklist is the same as the BIP 78 sender\nchecklist.
\nThe Payjoin Directory provides a rendezvous point for senders and\nreceivers to exchange messages. The directory stores Payjoin payloads to\nsupport asynchronous communication. Async Payjoin requests must be\nsubmitted as encapsulated messages to the directory's OHTTP Gateway.
\nThe wire format OHTTP request is specified in RFC\n9458. HPKE\nrequires the directory's OHTTP key configuration. The plaintext is a binary\nencoded HTTP request (RFC 9292)\nintended for the OHTTP target resource, usually a mailbox endpoint, padded to\n8104 bytes with random data.
\nOHTTP Encapsulated Request Byte Representation (8192 bytes total)\n+--------------+-------------------------+------------------------------------------+\n| OHTTP Header | HPKE KEM | Ciphertext |\n| (7 bytes) | Uncompressed Public Key | (8120 bytes = 8192-65-7) +\n| | (65 bytes) +-----------------------------+------------+\n| | | Padded BHTTP Request | AEAD Tag |\n| | | (8104 bytes = 8192-65-16-7) | (16 bytes) |\n+--------------+-------------------------+------------------------------------------+\nResponse encryption uses the Export functionality of the request HPKE context to\nestablish a shared secret, and therefore consists of a 32 byte nonce followed by\nthe AEAD ciphertext and tag.
\nOHTTP Encapsulated Response Byte Representation (8192 bytes total)\n+---------------------+------------------------------------------+\n| Nonce | Ciphertext |\n| (32 bytes) | (8160 bytes = 8192-32) +\n| +-----------------------------+------------+\n| | Padded BHTTP Response | AEAD Tag |\n| | (8144 bytes = 8192-32-16) | (16 bytes) |\n+---------------------+------------------------------------------+\nGET requests on an empty mailbox should block until a message is posted\nor a timeout occurs. The timeout should be 30 seconds because that will\nnot exceed the default timeout for most HTTP clients.
\nThe directory may optionally accept HTTP/1.1 POST requests without OHTTP\nto mailbox endpoint URLs for backwards compatibility with BIP 78 senders.
\n .-------------------------------------------.\n | Payjoin Directory |\n +--------+ +-----------+ | +-------------+ +--------------+ |\n | Client | | OHTTP | | | OHTTP | | HTTP | |\n | | | Relay | | | Gateway | | Resource | |\n +---+----+ +------+----+ | +-----+-------+ +------+-------+ |\n | | `--------|-----------------------|----------'\n | Relay Request | | |\n | [ + Encapsulated | | |\n | Request ] | | |\n +------------------->| Gateway Request | |\n | | [ + Encapsulated | |\n | | Request ] | |\n | +------------------->| Request |\n | | +---------------------->|\n | | | |\n | | | Response |\n | | Gateway |<----------------------+\n | | Response | |\n | | [ + Encapsulated | |\n | | Response ] | |\n | Relay |<-------------------+ |\n | Response | | |\n | [ + Encapsulated | | |\n | Response ] | | |\n |<-------------------+ | |\n | | | |\nRFC 9458 requires each OHTTP Relay to be configured to forward requests\nto exactly one OHTTP Gateway. This requirement prevents receivers from\nbeing able to choose any directory, and senders from choosing relays\nindependently. Without addressing this limitation, senders would have to\nknow which relays are appropriate to use for each directory, creating a\ntendency for one directory and its affiliated relays to monopolize the\nprotocol.
\nIn order to allow OHTTP Relays to be used with any directory, a\ndirectory's OHTTP Gateway may advertise this allowed purpose. This\nadvertisement prevents OHTTP Relays from acting as open internet proxies,\nwhich would otherwise allow anonymized access to arbitrary resources and\nexpose them to denial-of-service attacks, as well as other forms of abuse.\nWhen the directory receives a GET request to the /.well-known/ohttp-gateway\npath with an allowed_purposes query parameter, its response body\nshould contain a magic string in the same format as a TLS ALPN protocol\nlist (a U16BE length encoded list of U8 length encoded strings). The\nmagic string is BIP77 454403bb-9f7b-4385-b31f-acd2dae20b7e, offering\nan unambiguous signal to relays that this OHTTP Gateway will accept\nrequests associated with this purpose from any relay.
By supporting this allowed_purposes parameter, the directory signals\nto OHTTP Relays that it is willing to handle requests related to BIP 77,\nremoving the RFC 9458's requirement that relays and\nGateways be configured in a one-to-one relationship.
In order to simplify parsing and allow QR encoders to use Alphanumeric\nQR\nmode,\nwhich is more compact than Byte mode, the mailbox endpoint URL,\nincluding the fragment parameters, is encoded in uppercase.
\nUnlike Bitcoin URI parameters, which require switching back to Byte\nmode, the use of the URL fragment for session-specific parameters makes\nit possible to stay in Alphanumeric mode.
\nThe order of fragment parameters, Bitcoin URI parameters, as well as in the\nsender's optional parameters have no defined meaning.
\nIn the BIP 21 URI, the pj parameter mailbox endpoint URL SHOULD be the last\nparameter to avoid QR mode switching.
Since variations might create a fingerprint for particular wallet software,\nthis document requires that fragment parameters MUST appear in reverse\nlexicographical order.
\nThe directory may hold a message for an offline Payjoin client until that\nclient comes online. However, the BIP 78 spec \nrecommends\nbroadcasting Original PSBTs in the case of an offline counterparty.\nDoing so exposes a naïve, surveillance-vulnerable transaction, which\nPayjoin intends to avoid.
\nBecause BIP 78 is a synchronous protocol without a standard expiration\nmechanism, and automated receivers are vulnerable to probing attacks,\nBIP 78 encourages receivers to broadcast the Original PSBT after some\nundefined expiration time.
\nBecause BIP 77 is an asynchronous protocol, it requires an explicit \nsession-specific fragment\nparameter, EX, to\ncommunicate this expiration time to the sender.
There is no way for a sender to prevent a receiver from broadcasting the\nfallback transaction extracted from the Original PSBT before the\nreceiver-specified expiration time.
\n64 bits are sufficient to make the probability of experiencing a random\ncollision negligible. As of writing, the UTXO set has ~2^28 elements.\nThis is a very loose upper bound for the number of concurrent (non-spam)\nsessions, for which the probability of a random collision will be less\nthan 1%. The actual number of sessions will of course be (orders of\nmagnitudes) lower given that sessions are short-lived. With ~2^21\nsessions (a loose bound on number of transactions that can be confirmed\nin 24 hours) the probability is less than 1e-6. These figures bound the\nprobability of a collision existing anywhere in the entire set, whereas\nthe probability for an individual session to experience a collision is\n<< 1e-10 in either case.
\nComplete UTXO data is required because this information is required for\nsigning and calculating fees for some input types.
\nHTTP is ubiquitous. Using simple HTTP polling allows even Bitcoin Core\nto consider an implementation. Unlike a WebSockets protocol, plain HTTP\ncan benefit from metadata protection by using Oblivious HTTP.
\nOHTTP protects sender and receiver IP addresses both from one another\nand from the directory. This makes it more difficult for a directory to\ncorrelate many Payjoin transactions with specific IP addresses.
\nOHTTP relays can be run as basic HTTP proxies from wallet providers or\nthird parties.
\nEncapsulated OHTTP payloads seen by the relay and directory, and\nencrypted messages seen by the directory, are constructed to be uniform\nso that these third-party services are unable to distinguish between\nthem.
\nEncapsulated OHTTP messages are 8192 bytes long, and begin with a\ncleartext OHTTP header and an uncompressed key which is distinguishable\nfrom random bytes but uniform across different encapsulated requests.
\nEnd-to-end encrypted messages are 7168 bytes long, and should be\nindistinguishable from uniformly random bytes.\nElligatorSwift as defined in BIP 324\nis used to encode encapsulated HPKE public keys prepended to the HPKE ciphertext\nso that the directory can't distinguish between key material, the\nciphertext, and randomness. This ensures the two different protocol\nmessages are indistinguishable from each other as well as any protocol\nextensions.
\nThese padded sizes are sufficient for most PSBTs without exceeding the \n8KB\nlimit\nof many HTTP/1.1 web servers. 8KB is also too small for image sharing,\nmaking misuse of the directory impractical.
\nThe typical zero padding recommended by the BHTTP\nspecification\nwould make future use of multi-hop OHTTP inspired by the Sphinx mix\nformat detectable from the\npoint of view of the directory. Random padding is allowed so long as the BHTTP\nencoded request is not truncated.
\nBy randomly padding OHTTP messages, any future use of such techniques would be\nindistinguishable from clients that only implement standardized OHTTP. Since\nthis would limit a malicious directory's ability to censor any such requests in\nthe future, and such requests significantly bolster the privacy threat model\nagainst malicious OHTTP relays or traffic analysis by a global passive\nadversary, it is desirable to do so for standard OHTTP requests as well.
\nRFC 9180 Hybrid Public Key\nEncryption\n(HPKE) is a modern IETF standard for secure\nmessage exchange without TLS, since TLS is not available in Bitcoin Core.
\nThis proposal uses DHKEM(Secp256k1, HKDF-SHA256) and\nChaCha20Poly1305 AEAD for both OHTTP encapsulation and for end-to-end\nencryption between the sender and receiver.
The receiver transmits its receiver key in receiver fragment\nparameters. The sender shares\nits reply key along with the Original PSBT. These keys are ephemeral and\nmust only be used for a single Payjoin Session.
\nSecp256k1-based DHKEM for\nHPKE\nis most appropriate because of secp256k1's availability in bitcoin\ncontexts.
\nThis authenticated encryption with additional data \nalgorithm\nis standardized in RFC\n8439 and has high\nperformance. ChaCha20Poly1305 AEAD has been implemented in Bitcoin\nCore for \nBIP 324 Encrypted\nTransport\nas well. This has widespread support in browsers and common\ncryptographic libraries. AES-GCM is more widespread but slower without\nhardware support and not typically already a dependency in bitcoin software.
\nSHA-256 is necessarily available in bitcoin contexts.
\nIn addition to the attack vectors and mitigations in\nBIP 78,\nthis proposal has the following attack vectors.
\nSince each mailbox stores arbitrary encrypted payloads, directories are\nvulnerable to flooding. To mitigate such denial of service attacks,\ndirectory operators may respond with 401 unauthorized unless an\nauthorization token is provided. Authorization tokens must be unlinkable\nto preserve client privacy. A specific unlinkable authorization token\nmechanism is out of the scope of this proposal.
Oblivious HTTP must be used to protect the IP addresses of both sender\nand receiver from the directory. This requires an OHTTP Key\nConfiguration to be shared in the Payjoin URI and for the directory to\nsupport Oblivious HTTP.
\nUnlike BIP 78 implementations, sender and receiver clients will only see\nthe IP address of the directory and not that of the client they are\ninteracting with.
\nSenders that submit requests directly to the directory, without using\nan OHTTP Relay, may reveal their IP address to the receiver since that\nreceiver also specifies the directory.
\nSenders not supporting Payjoin will just ignore the pj parameter and\nproceed to typical address-based transaction flows.
All Payjoin versions use Bitcoin URIs.\nReceivers may choose to accept BIP 78 payloads at their discretion.
\nA BIP 78 sender posts their request to the directory, which stores\nand forwards it to the BIP 77 receiver. A backwards-compatible\nreceiver proceeds with the BIP 78 checks if the encapsulated response\nbody is UTF-8 plaintext, signifying BIP 78. In order to service the\nrequest, a BIP 78 response must be returned to the sender within 30\nseconds or else the directory should respond with an unavailable JSON\nerror code as defined in BIP\n78.
When responding to a BIP 78 sender, the receiver MUST NOT HPKE-encrypt\nthe Proposal PSBT. The receiver MUST send the Proposal PSBT as the\nbody of a PUT request, with the body being the base64-encoded PSBT,\nencoded as ASCII bytes. The target mailbox endpoint MUST be the\nreceiver's own mailbox (the same mailbox at which the sender posted the\nOriginal PSBT), because a BIP 78 sender provides no reply key from which\na sender-side reply mailbox could be derived. The PUT request is then\nOHTTP-encapsulated to the directory's OHTTP Gateway as for any other\nPayjoin Directory interaction.
\nA production reference implementation client can be found at\nhttps://crates.io/crates/payjoin-cli. Source code for the clients, the\ndirectory, and development kit may be found here:\nhttps://github.com/payjoin/rust-payjoin. Source code for an Oblivious\nHTTP relay implementation may be found here:\nhttps://github.com/payjoin/ohttp-relay.
\n+ to - to improve\ncompatibility with generic URI parsing libraries, and order them\nlexicographically. + can cause issues due to a common convention (not\nspecified in RFC 3986, but in RFC 1866, in relation to HTML form\nsubmission and query parameters) of interpreting + as when decoding\nURIs.