From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id CB754C0032 for ; Wed, 9 Aug 2023 17:33:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A007140525 for ; Wed, 9 Aug 2023 17:33:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A007140525 Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev header.a=rsa-sha256 header.s=protonmail header.b=T9RkwaJq X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.065 X-Spam-Level: X-Spam-Status: No, score=-0.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LONGWORDS=2.035, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T3lkckunbPW for ; Wed, 9 Aug 2023 17:33:05 +0000 (UTC) X-Greylist: delayed 73630 seconds by postgrey-1.37 at util1.osuosl.org; Wed, 09 Aug 2023 17:33:05 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1860B40280 Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) by smtp2.osuosl.org (Postfix) with ESMTPS id 1860B40280 for ; Wed, 9 Aug 2023 17:33:04 +0000 (UTC) Date: Wed, 09 Aug 2023 17:32:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ngould.dev; s=protonmail; t=1691602381; x=1691861581; bh=C2jlF1G4pRi0PHHapti1cECeRlrtPCMsLDkPGSeuDyM=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=T9RkwaJq/As9iO5xiSgpM64ybfiOhqTTdJfI3WifYalMvmBCF4h81JdpsVDNb1yhq zcu3lxuY4v+jKhpWAgpuW7YJ/t1UO/7YgIFsw+2TZ6Yh3YZrdluf29ynmlZ/N/VOE9 nlvTcPzCbc/tFPizYiUaNtpzV0kMVJgUt4CEhSqw= To: bitcoin-dev@lists.linuxfoundation.org From: Dan Gould Message-ID: <7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev> Feedback-ID: 13175031:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 09 Aug 2023 23:17:53 +0000 Subject: [bitcoin-dev] BIP for Serverless Payjoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2023 17:33:07 -0000 Hi all, The Serverless Payjoin idea has come a long way toward formal specification= of a Payjoin version 2. In the spirit of BIP 2, I=E2=80=99m sharing an int= ermediate draft of the BIP here before opening a draft on GitHub for the BI= P editors, and before this exact specification has a complete reference imp= lementation. The draft does reference two proof of concept payjoin implemen= tations, one demonstrating use of symmetric cryptography, and the other asy= nchronous messaging and backwards compatibility. I=E2=80=99ve updated the Serverless Payjoin gist to reflect this draft spec= ification https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9= in order to preserve the edit history before opening a bips PR. The specifics have changed significantly compared to the first mailing list= post to reflect feedback. Looking forward to hear your thoughts. Dan 
BIP: ???
Layer: Applications
Title: Payjoin Version 2: Serverless Payjoin
Author: Dan Gould 
Status: Draft
Replaces: 78
Type: Standards Track
Created: 2023-08-08
License: BSD-2-Clause
=3D=3DAbstract=3D=3D This document proposes a backwards-compatible second version of the payjoin= protocol described in [[bip-0078.mediawiki|BIP 78]], allowing complete pay= join receiver functionality including payment output substitution without r= equiring them to host a secure public endpoint. This requirement is replace= d with an untrusted third-party relay and streaming clients which communica= te using an asynchronous protocol and authenticated encrypted payloads. =3D=3DCopyright=3D=3D This BIP is licensed under the 2-clause BSD license. =3D=3DMotivation=3D=3D Payjoin solves the sole privacy problem left open in the bitcoin paper, tha= t transactions with multiple inputs "necessarily reveal that their inputs w= ere owned by the same owner." Breaking that common-input ownership assumpti= on and others requires input from multiple owners. Cooperative transaction = construction also increases transaction throughput by providing new opportu= nity for payment batching and transaction cut-through. Version 1 coordinates payjoins over a public server endpoint secured by eit= her TLS or Tor onion hidden service hosted by the receiver. Version 1 is sy= nchronous, so both sender and reciever must be online simultaneously to pay= join. Both requirements present significant barriers for all but sophistica= ted server operators or those wallets with complex Tor integration. These b= arriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-= January/018358.html|regarded]] as limits to payjoin adoption. The primary goal of this proposal is to provide a practical coordination me= chanism to be adopted in a vast majority of wallet environments. This is re= alized as a simple protocol built on bitcoin URI requests, web standards, c= ommon crypto, and minimal dependencies. =3D=3D=3DRelation to BIP 78 (Payjoin version 1)=3D=3D=3D The message payloads in this version parrallel those used in BIP 78 while b= eing encapsulated in authenticated encryption, forgoing HTTP messaging for = WebTransport streaming of asynchronus interactions, and leveraging PSBT ver= sion 2. The BIP 78 standard allows for an [[https://github.com/bitcoin/bips/blob/ma= ster/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin server|]= ] to operate separately from the so-called "payment server" responsible for= generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawik= i|BIP 21]] request URIs. Because BIP 78 messages are neither authenticated = nor encrypted a malicious unsecured payjoin server is able to modify the Pa= yjoin PSBT in flight, thus requiring [[payment output substitition]] to be = disabled. Output substitition is useful for a number of block space optimiz= ations, including payment batching and transaction cut-through. This propos= al introduces authentication and encryption to secure output substition whi= le using a relay without compromising sender or receiver privacy. Although unsecured payjoin server separation is mentioned in BIP 78, no kno= wn specification or implementation of one exists. This document specifies o= ne to be backwards compatible with version 1 senders. Receivers responding = to version 1 senders must disable output substitution their payloads are pl= aintext so they may payjoin without the risk of the relay stealing funds. The protocols in this document reuse BIP 78's BIP 21 URI parameters. A Fall= back PSBT timeout parameter is introduced which may also help coordinate th= e synchronous version 1 protocol. =3D=3D=3DRelation to Stowaway=3D=3D=3D [[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoots/STOWAW= AY.md|Stowaway]] is a payjoin coordination mechanism which depends on Tor, = a third-party relay, and the [[https://samouraiwallet.com/paynym|PayNym]] [= [https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki|BIP 47]] Pa= yment codes directory for subdirectory identification and encryption. The p= ayjoin version 2 protocol uses one-time symmetric keys for relay subdirecto= ry identification, authentication, and encryption instead of BIP 47 public = keys derived from the wallet. Payjoin version 2 also supports asynchronous = messaging, in contrast to online Stowaway's synchronous HTTP-based messagin= g. Offline stowaway may depends on manual message passing rather than an as= ynchronous network protocol. Successful Stowaway execution results in 2-out= put transactions, while BIP 79, 78, and this work may produce batched trans= actions with many outputs. =3D=3DSpecification=3D=3D =3D=3D=3DOverview=3D=3D=3D Payjoin requests are made using familiar BIP 21 URIs. Instead of a public H= TTP endpoint, this scheme allows a WebTransport client to enroll with a rel= ay server to receive payjoin. Relays may optionally require an authorizatio= n credential before allocating resources in order to prevent DoS attacks. S= ender and receiver payloads are buffered at the relay to support asynchrono= us interaction. Symmetric authenticated encryption (ChaCha20-Poly1305 AEAD)= prevents the relay from snooping on message contents or forging messages. = Aside from a pre-shared secret and relayed asynchronus networking, the vers= ion 2 messaging takes much the same form as the existing BIP 78 specificati= on. =3D=3D=3DBasic scheme=3D=3D=3D The recipient first generates a 256-bit key psk. This pre-shar= ed key will be the basis of end-to-end authenticated encryption and identif= ication of a particular payjoin over the relay. Rather than hosting a public server, they start a streaming session to rece= ive messages and allocate a subdirectory from which to relay messages. The = first message must include the first 4 bytes of the Sha256 hash of their psk to be enrolled as a subdirectory identifier. The next messag= e streamed from the relay to sender includes the enrolled subdirectory payj= oin endpoint. After enrollment, they await a payjoin request on a session i= dentified by the subdirectory. Out of band, the receiver shares a [[https:/= /github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] payjoin ur= i including the relay endpoint in the pj=3D query parameter an= d the pre-shared key in a new psk=3D query parameter. The sender constructs an encrypted and authenticated payload containing a P= SBT and optional parameters similar to BIP 78. The resulting ciphertext ens= ures message secrecy and integrity when streamed to the recipient by the re= lay-hosted subdirectory pj=3D endpoint. The sender's request is relayed to the receiver over a streaming session at= the subdirectory identified by the hash of psk. Messages are = secured by symmetric cipher rather than TLS or Onion routing session key. S= ender and receiver may experience network interruption and proceed with the= protocol since their request and response are buffered at the Payjoin rela= y subdirectory. =3D=3D=3DPayjoin version 2 messaging=3D=3D=3D Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/master/bip-0= 370.mediawiki|BIP 370 PSBT v2]] format to fascilitate PSBT mutation. The payjoin version 2 protocol takes the following steps: * The recipient sends the first 4 bytes of H(psk) and optional= authentication credential according to [[#receiver-relay-enrollment|receiv= er relay enrollment]] protocol. It may go offline and replay enrollment to = come back online. * Out of band, the receiver of the payment, shares a bitcoin URI with the s= ender including a pj=3D query parameter describing the relay s= ubdirectory endpoint and psk=3D parameter with base64 encoded = 256-bit secret key. To support version 1 senders the relay acts as an unsec= ured payjoin server so pjos=3D0 must be specified in the URI. = Version 2 senders may safely allow output substitution regardless. * The sender creates a valid PSBT according to [[https://github.com/bitcoin= /bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiver c= hecklist]] formatted as PSBTv2. We call this the Fallback PSBT= . This Fallback PSBT and optional sender parameters are encrypted and authe= nticated with the psk using ChaCha20Poly1305 and streamed to t= he relay subdirectory endpoint. * The sender awaits a response from the relay stream containing an encrypte= d Payjoin PSBT. It can replay the Fallback PSBT t= o request a response if it goes offline. * The request is stored in the receiver's subdirectory buffer. * Once the receiver is online, it awaits a stream of request updates from t= he relay. The receiver decrypts aund authenticates the payload then checks = it according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#rece= ivers-original-psbt-checklist|the receiver checklist]]. It updates it to in= clude new signed inputs and outputs invalidating sender signatures, and may= adjust the fee. We call this the Payjoin PSBT. * It responds with the Payjoin PSBT encrypted then authenticat= ed under psk using ChaCha20Poly1305. * The relay awaits a connection from the sender if it goes offline. Upon co= nnection, it relays the encrypted Payjoin PSBT to the sender. * The sender validates the Payjoin PSBT according to [[#sender= s-payjoin-psbt-checklist|the sender checklist]], signs its inputs and broad= casts the transaction to the Bitcoin network. The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as bytes. The Fallback PSBT MUST: * Include complete UTXO data. * Be signed. * Exclude unnecessary fields such as global xpubs or keypath information. <= !-- I believe PSBTv2 obviates this requirement --> * Set input and output Transaction Modifiable Flags to 1 * Be broadcastable. The Fallback PSBT MAY: * Include outputs unrelated to the sender-receiver transfer for batching pu= rposes. * Set SIGHASH_SINGLE Transaction Modifiable Flags flags to 1 The Payjoin PSBT MUST: * Include all inputs from the Fallback PSBT. * Include all outputs which do not belong to the receiver from the Fallback= PSBT. * Include complete UTXO data. The Payjoin PSBT sender MAY: * Add, remove or modify Fallback PSBT outputs under the control of the rece= iver (i.e. not sender change). The Payjoin PSBT MUST NOT: * Shuffle the order of inputs or outputs; the additional outputs or additio= nal inputs must be inserted at a random index. * Decrease the absolute fee of the original transaction. =3D=3D=3DReceiver's Payjoin PSBT checklist=3D=3D=3D Other than requiring PSBTv2 the receiver checklist is the same as the [[htt= ps://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-origi= nal-psbt-checklist|the BIP 78 receiver checklist]] =3D=3D=3DSender's Payjoin PSBT checklist=3D=3D=3D The version 2 sender's checklist is largely the same as the [[https://githu= b.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-checklist|= the BIP 78 checklist]] with the exception that it expects ALL utxo data to = be filled in. BIP 78 required sender inputs UTXO data to be excluded from t= he PSBT which has caused many headaches since it required the sender to add= them back to the Payjoin proposal PSBT. Version 2 has no such requirement. =3D=3D=3DRelay interactions=3D=3D=3D The Payjoin Relay provides a rendezvous point for sender and receiver to me= et. It stores Payjoin payloads to support asynchronous communication. It is= available on the open internet over HTTPS to accept both WebTransport for = Payjoin version 2, accepting encrypted payloads, and optionally HTTP/1.1 to= support backwards compatible Payjoin version 1 requests. =3D=3D=3DReceiver interactions=3D=3D=3D =3D=3D=3D=3DRelay enrollment=3D=3D=3D=3D Receivers must enroll to have resources allocated on a relay. Sessions may = begin by having a receiver send the first 4 bytes of the Sha256 hash of the= ir psk to the relay. The receiver returns the subdirectory end= point url. Enrollment may be replayed in case the receiver goes offline. Optionally, before returning the uri the receiver may request an authentica= tion token by presenting a message containing only the word Authentic= ate: after which the receiver is required to submit an= Authenticate: including the token from the Relay out = of band. If authentication fails an error is returned. In the case a relay is operated by an exchange, it may give out authenticat= ion tokens for users of its app, or may require some proof of work out of b= and. Tokens should be anonymous credentials from the relay describing the p= arameters of their authorization. Specific credentialing is out of the scop= e of this proposal. =3D=3D=3D=3DReceiver Payjoin PSBT response=3D=3D=3D=3D The receiver streams the base64 Payjoin PSBT as encrypted bytes from ChaCha= 20Poly1305 under psk. =3D=3D=3DSender interactions=3D=3D=3D The sender starts a WebTransport session with the relay at the Payjoin endp= oint URI provided by the receiver. It sends the following payload and await= s a relayed response payload from the receiver. =3D=3D=3D=3DVersion 2 Fallback PSBT request=3D=3D=3D=3D The version 2 Fallback PSBT Payload is constructed in JSON before being enc= rypted as follows. 
{
"psbt": "",
"params": {
"param1": "",
"param2": "",
...
}
}
The payload must be encrypted using ChaCha20Poly1305 by the sender using th= e psk. =3D=3D=3D=3DVersion 1 Fallback PSBT request=3D=3D=3D=3D The message should be the same as version 2 but unencrypted, as version 1 i= s unaware of encryption when using an unsecured payjoin server. The Relay s= hould convert the PSBT to PSBTv2 and construct the JSON payload from the HT= TP request body and optional query parameters. Upon receiving an unencrypte= d PSBTv2 response from a receiver, it should convert it to PSBTv0 for compa= tibility with BIP 78. =3D=3D=3DAsynchronous relay buffers=3D=3D=3D Each receiver subdirectory on the relay server has a buffer for requests an= d one for responses. Each buffer updates listeners through awaitable events= so that updates are immediately apparent to relevant client sessions. =3D=3D=3DBIP 21 receiver parameters=3D=3D=3D A major benefit of BIP 78 payjoin over other coordination mechanisms is its= compatibility with the universal BIP 21 bitcoin URI standard. This proposal defines the following new [[https://github.com/bitcoin/bips/b= lob/master/bip-0021.mediawiki|BIP 21 URI]] parameters: * psk: the pre-shared symmetric key for encryption and authent= ication with ChaCha20-Poly1305 * exp: represents a request expiration after which the receive= r reserves the right to broadcast the Fallback and ignore requests. BIP 78's BIP 21 payjoin parameters are also valid for version 2. =3D=3D=3DOptional sender parameters=3D=3D=3D When the payjoin sender posts the original PSBT to the receiver, it can opt= ionally specify the following HTTP query string parameters: * v: represents the version number of the payjoin protocol tha= t the sender is using. This version is 2. BIP 78's optional query parameters are also valid as version 2 parameters. =3D=3DRationale=3D=3D =3D=3D=3DRequest expiration & fallback=3D=3D=3D The relay may hold a request for an offline payjoin peer until that peer co= mes online. However, the BIP 78 spec recommends broadcasting request PSBTs = in the case of an offline counterparty. Doing so exposes a na=C3=AFve, surv= eillance-vulnerable transaction which payjoin intends to avoid. The existing BIP 78 protocol has to be synchronous only for automated endpo= ints which may be vulnerable to probing attacks. It can cover this tradeoff= by demanding a fallback transaction that would not preserve privacy the sa= me way as a payjoin. BIP 21 URI can communicate a request expiration to all= eviate both of these problems. Receivers may specify a deadline after which= they will broadcast this fallback with a new expiration parameter ex= p=3D. =3D=3D=3DWebTransport=3D=3D=3D Many transport protocols are good candidates for Serverless Payjoin functio= nality, but WebTransport stands out in its ability to stream and take advan= tage of QUIC's performance in mobile environments. In developing this BIP, = serverless payjoin proofs of concept using TURN, HTTP/1.1 long polling, Web= Sockets, Magic Wormhole, and Nostr have been made. Streaming allows the rel= ay to have more granular and asynchronous understanding of the state of the= peers, and this protcol is designed specifically to address the shortcomin= gs of an HTTP protocol's requirement to receive from a reliable, always-onl= ine connection. While WebTransport and HTTP/3 it is built on are relatively new, widespread= support across browsers assures me that it is being accepted as a standard= and even has a fallback to HTTP/2 environments. Being built on top of QUIC= allows it to multiplex connections from a relay to multiple peers which ma= y prove advantageous for later payjoin protocols between more than two part= icipants contributing inputs, such as those used to fund a lightning node w= ith channels from multiple sources in one transaction, or those with threat= models more similar to ZeroLink CoinJoin. While Nostr is fascinating from the perspective of censorship resistance, t= he backwards compatibility with Payjoin v1 would mean only custom Nostr Pay= join relays exposing an https endpoint would be suitable. Nostr transport i= s also limited by the performance of WebSockets, being an abstraction on to= p of that protocol. If Nostr authentication were used instead of a symmetri= c psk then those keys would also need to be communicated out o= f band and complicate the protocol. There is nothing stopping a new version= of this protocol or a NIP making Payjoin version 2 possible over Nostr sho= uld Payjoin censorship become a bottleneck in the way of adoption. WebTransport is already shipped in both Firefox, Chrome, h3 in Rust, Go, an= d all popular languages. There is also [[https://w3c.github.io/p2p-webtrans= port/|a working draft for full P2P WebTransport]] without any relay, which = a future payjoin protocol may make use of. =3D=3D=3DChaCha20Poly1305 AEAD=3D=3D=3D This authenticated encryption with additional data [[https://en.wikipedia.o= rg/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 and has h= igh performance. ChaCha20Poly1305 AEAD seems to be making its way into bitc= oin by way of [[https://github.com/bitcoin/bips/blob/master/bip-0324.mediaw= iki|BIP 324]] as well. The protocol has widespread support in browsers, Ope= nSSL and libsodium. AES-GCM is more widespread but is both older, slower, a= nd not a dependency in bitcoin software. secp256k1 asymmetric cryptography could be used, but symmetric encryption a= llows for many fewer messages to be sent, a single ephemeral key, and seems= suitable given the one time use of BIP 21 URIs for Payjoin. Payjoin alread= y requires base64 encoding for PSBTs, so we have it available to encode the= 256-bit psk in the BIP 21 parameter. =3D=3D=3DPSBT Version 2=3D=3D=3D The PSBT version 1 protocol was replaced because it was not designed to hav= e inputs and outputs be mutated. Payjoin mutates the PSBT, so BIP 78 uses a= hack where a new PSBT is created by the receiver instead of mutating it. T= his can cause some strange behaviors from signers who don't know where to l= ook to find the scripts that they are accountable for. PSBT version 2 makes= mutating a PSBT's inputs and outputs trivial. It also eliminates the trans= action finalization step. Receivers who do not understand PSBT version 1 ma= y choose to reject Payjoin version 1 requests and only support PSBT version= 2. =3D=3D=3DAttack vectors=3D=3D=3D Since relays store arbitrary encrypted payloads to the tragedy of the commo= ns and denial of service attacks. Relay operators may impose an authenticat= ion requirement before they provide relay service to receivers to mitigate = such attacks. Since psk is a symmetric key, the first message containing the= sender's original PSBT does not have forward secrecy. Since relay buffers = are associated with a single ephemeral relay directory, to support request-= response simplicity of version 1, this seems appropriate. Since the Fallback PSBT is valid, even where exp=3D is specifi= ed, the receiver may broadcast it and lose out on ambiguous privacy protect= ion from payjoin at any time. Though unfortunate, this is the typical bitco= in transaction flow today anyhow. =3D=3D=3DNetwork privacy=3D=3D=3D Unlike BIP 78 implementations, sender and receiver peers will only see the = IP address of the relay, not their peer's. Relays may be made available via= Tor hidden service or Oblivious HTTP in addition to IP / DNS to allow eith= er of the peers to protect their IP from the relay with without requiring b= oth peers to use additional network security dependencies. =3D=3DBackwards compatibility=3D=3D The receivers advertise payjoin capabilities through [[https://github.com/b= itcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]]. Senders not supporting payjoin will just ignore the pj=3D para= meter and proceed to typical address-based transaction flows. req-pj= =3D may be used to compel payjoin.=20 Receivers may choose to support version 1 payloads. Version 2 payjoin URIs = should enable pjos=3D0 so that these v1 senders disable output= substitution since the v1 messages are neither encrypted nor authenticated= , putting them at risk for man-in-the-middle attacks otherwise. The relay p= rotocol should carry on as normal, validating based on HTTP headers and con= structing an unencrypted Version 2 payload from optional query parameters, = and PSBT in the body. The BIP 78 error messages are already JSON formatted, so it made sense to r= ely on the same dependency for these payloads and error messages. =3D=3DReference implementation=3D=3D An early proof of concept draft reference implementation can be found at ht= tps://github.com/payjoin/rust-payjoin/pull/78. It implements an asynchronou= s payment flow using WebSockets using PSBTv1 without encryption. Another re= ference can be found at https://github.com/payjoin/rust-payjoin/pull/21 whi= ch uses HTTP long polling for transport and Noise NNpsk0 for crypto. Recent= ly, I've come to realize the rationale for WebTransport, PSBTv2, and ChaCha= 20-Poly1305 AEAD substitutions and am working on an implementation includin= g this exact specification, but wanted to get early feedback on this design= in the spirit of BIP 2. =3D=3DAcknowledgements=3D=3D Thank you to OpenSats for funding this pursuit, to Human Rights Foundation = for putting a bounty on it and funding invaluable BOB Space space support, = who I owe a thank you to as well. Thank you to Ethan Heilman, Nicolas Dorie= r, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, Mike Sch= midt, Murch, D=C3=A1vid Moln=C3=A1r, Lucas Ontiviero, and uncountable twitt= er plebs for feedback that has turned this idea from concept into draft, to= Mike Jarmuz for suggesting that I write a BIP, and to Satsie for writing t= he "All About BIPS" zine which I've referenced a number of times in the dra= fting process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for h= acking on the first iOS Payjoin receiver and uncovering the problem that th= is solves in the first place.