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 CB799C0032 for ; Thu, 10 Aug 2023 15:38:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A0BAC417B7 for ; Thu, 10 Aug 2023 15:38:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A0BAC417B7 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=mQRzu4KC X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.064 X-Spam-Level: X-Spam-Status: No, score=-0.064 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, FREEMAIL_FROM=0.001, 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 0bKsjiMRFVnf for ; Thu, 10 Aug 2023 15:38:03 +0000 (UTC) X-Greylist: delayed 2453 seconds by postgrey-1.37 at util1.osuosl.org; Thu, 10 Aug 2023 15:38:02 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C70DB404AE Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by smtp2.osuosl.org (Postfix) with ESMTPS id C70DB404AE for ; Thu, 10 Aug 2023 15:38:02 +0000 (UTC) Date: Thu, 10 Aug 2023 15:37:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1691681878; x=1691941078; bh=8dTiEf9QjaOCaw35cqh5AYAOt/FG01gVRH4V/usoOPw=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=mQRzu4KCm4Kw6Z1+XQSLMASgu9EA6AL3EpDEkJfZ9sZFsrLjQvHrrMhvy67SkcyO1 Dcp763wuqTT0nXwvSGEu7v6gwmn0EBHxrdjCzHERAG/wY5Xfssatmlnfzr6fzML+bu 55WtaQys1pmjKAO0Jjoci2fyRvzXp1OniNcPWjqNzqhg810S7NOE2L+uCjwPvKmaZe aers/rVtxFpKg7EjpCWjGNtpc8akKJDto/o13wIBQiU0sYUlnN6aeXyU1pDIb7mBV0 HWmE3Pt9Mym6i1a9DVl4U+/K/cA8Vo9s9GMlaTIGBD3xk60JZhzA2Cfy9eiGXFJpRT b71ruQWHt3B6w== To: Dan Gould , Bitcoin Protocol Discussion From: AdamISZ Message-ID: In-Reply-To: <7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev> References: <7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev> Feedback-ID: 11565511:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 10 Aug 2023 16:21:20 +0000 Subject: Re: [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: Thu, 10 Aug 2023 15:38:05 -0000 Hi Dan, A couple more more thoughts: > 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. You're sending the symmetric secret key out of band; but isn't this obscuri= ng the question of securely sharing the secret key? Did you consider DH-ing= this as other protocols do? At the very least I would claim that it's like= ly that implementers might be sloppy here; at the most I would claim this i= s just insecure full stop. About attack vectors: > Since relays store arbitrary encrypted payloads to the tragedy of the com= mons and denial of service attacks. Relay operators may impose an authentic= ation requirement before they provide relay service to receivers to mitigat= e such attacks. Isn't the most obvious concern with this architecture, that the relays have= metadata - most obviously, they can time correlate messages, with bitcoin = network events, so at the least they could tie transactions to clients. *If= * both parties use anonymised network connections then this is ameliorated = (though not removed) as a vector, but then we'd need to be clear that we *r= equire* those (e.g. Tor). Not sure if it's palatable to do this if otherwis= e, i.e. if we think the relays can tie network addresses to transactions? W= ell, not sure, but I'd expect it to be mentioned? Cheers, AdamISZ/waxwing Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, August 9th, 2023 at 11:32, Dan Gould via bitcoin-dev wrote: > Hi all, >=20 > The Serverless Payjoin idea has come a long way toward formal specificati= on of a Payjoin version 2. In the spirit of BIP 2, I=E2=80=99m sharing an i= ntermediate draft of the BIP here before opening a draft on GitHub for the = BIP editors, and before this exact specification has a complete reference i= mplementation. The draft does reference two proof of concept payjoin implem= entations, one demonstrating use of symmetric cryptography, and the other a= synchronous messaging and backwards compatibility. >=20 > I=E2=80=99ve updated the Serverless Payjoin gist to reflect this draft sp= ecification https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32= f9 in order to preserve the edit history before opening a bips PR. >=20 > The specifics have changed significantly compared to the first mailing li= st post to reflect feedback. Looking forward to hear your thoughts. >=20 > Dan >=20 > 
>=20
> BIP: ???
> Layer: Applications
> Title: Payjoin Version 2: Serverless Payjoin
> Author: Dan Gould d@ngould.dev
>=20
> Status: Draft
> Replaces: 78
> Type: Standards Track
> Created: 2023-08-08
> License: BSD-2-Clause
>
>=20 >=20 > =3D=3DAbstract=3D=3D >=20 > This document proposes a backwards-compatible second version of the payjo= in protocol described in [[bip-0078.mediawiki|BIP 78]], allowing complete p= ayjoin receiver functionality including payment output substitution without= requiring them to host a secure public endpoint. This requirement is repla= ced with an untrusted third-party relay and streaming clients which communi= cate using an asynchronous protocol and authenticated encrypted payloads. >=20 > =3D=3DCopyright=3D=3D >=20 > This BIP is licensed under the 2-clause BSD license. >=20 > =3D=3DMotivation=3D=3D >=20 > Payjoin solves the sole privacy problem left open in the bitcoin paper, t= hat transactions with multiple inputs "necessarily reveal that their inputs= were owned by the same owner." Breaking that common-input ownership assump= tion and others requires input from multiple owners. Cooperative transactio= n construction also increases transaction throughput by providing new oppor= tunity for payment batching and transaction cut-through. >=20 > Version 1 coordinates payjoins over a public server endpoint secured by e= ither TLS or Tor onion hidden service hosted by the receiver. Version 1 is = synchronous, so both sender and reciever must be online simultaneously to p= ayjoin. Both requirements present significant barriers for all but sophisti= cated server operators or those wallets with complex Tor integration. These= barriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202= 1-January/018358.html|regarded]] as limits to payjoin adoption. >=20 > The primary goal of this proposal is to provide a practical coordination = mechanism to be adopted in a vast majority of wallet environments. This is = realized as a simple protocol built on bitcoin URI requests, web standards,= common crypto, and minimal dependencies. >=20 > =3D=3D=3DRelation to BIP 78 (Payjoin version 1)=3D=3D=3D >=20 > The message payloads in this version parrallel those used in BIP 78 while= being encapsulated in authenticated encryption, forgoing HTTP messaging fo= r WebTransport streaming of asynchronus interactions, and leveraging PSBT v= ersion 2. >=20 > The BIP 78 standard allows for an [[https://github.com/bitcoin/bips/blob/= master/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin server= |]] to operate separately from the so-called "payment server" responsible f= or generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediaw= iki|BIP 21]] request URIs. Because BIP 78 messages are neither authenticate= d nor encrypted a malicious unsecured payjoin server is able to modify the = Payjoin PSBT in flight, thus requiring [[payment output substitition]] to b= e disabled. Output substitition is useful for a number of block space optim= izations, including payment batching and transaction cut-through. This prop= osal introduces authentication and encryption to secure output substition w= hile using a relay without compromising sender or receiver privacy. >=20 > Although unsecured payjoin server separation is mentioned in BIP 78, no k= nown specification or implementation of one exists. This document specifies= one to be backwards compatible with version 1 senders. Receivers respondin= g to version 1 senders must disable output substitution their payloads are = plaintext so they may payjoin without the risk of the relay stealing funds. >=20 > The protocols in this document reuse BIP 78's BIP 21 URI parameters. A Fa= llback PSBT timeout parameter is introduced which may also help coordinate = the synchronous version 1 protocol. >=20 > =3D=3D=3DRelation to Stowaway=3D=3D=3D >=20 > [[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoots/STOW= AWAY.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]] = Payment codes directory for subdirectory identification and encryption. The= payjoin version 2 protocol uses one-time symmetric keys for relay subdirec= tory identification, authentication, and encryption instead of BIP 47 publi= c keys derived from the wallet. Payjoin version 2 also supports asynchronou= s messaging, in contrast to online Stowaway's synchronous HTTP-based messag= ing. Offline stowaway may depends on manual message passing rather than an = asynchronous network protocol. Successful Stowaway execution results in 2-o= utput transactions, while BIP 79, 78, and this work may produce batched tra= nsactions with many outputs. >=20 > =3D=3DSpecification=3D=3D >=20 > =3D=3D=3DOverview=3D=3D=3D >=20 > Payjoin requests are made using familiar BIP 21 URIs. Instead of a public= HTTP endpoint, this scheme allows a WebTransport client to enroll with a r= elay server to receive payjoin. Relays may optionally require an authorizat= ion credential before allocating resources in order to prevent DoS attacks.= Sender and receiver payloads are buffered at the relay to support asynchro= nous interaction. Symmetric authenticated encryption (ChaCha20-Poly1305 AEA= D) prevents the relay from snooping on message contents or forging messages= . Aside from a pre-shared secret and relayed asynchronus networking, the ve= rsion 2 messaging takes much the same form as the existing BIP 78 specifica= tion. >=20 > =3D=3D=3DBasic scheme=3D=3D=3D >=20 > The recipient first generates a 256-bit key psk. This pre-sh= ared key will be the basis of end-to-end authenticated encryption and ident= ification of a particular payjoin over the relay. >=20 >=20 > Rather than hosting a public server, they start a streaming session to re= ceive messages and allocate a subdirectory from which to relay messages. Th= e first message must include the first 4 bytes of the Sha256 hash of their = psk to be enrolled as a subdirectory identifier. The next mess= age streamed from the relay to sender includes the enrolled subdirectory pa= yjoin endpoint. After enrollment, they await a payjoin request on a session= identified by the subdirectory. Out of band, the receiver shares a [[https= ://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] payjoin = uri including the relay endpoint in the pj=3D query parameter = and the pre-shared key in a new psk=3D query parameter. >=20 >=20 > The sender constructs an encrypted and authenticated payload containing a= PSBT and optional parameters similar to BIP 78. The resulting ciphertext e= nsures message secrecy and integrity when streamed to the recipient by the = relay-hosted subdirectory pj=3D endpoint. >=20 >=20 > The sender's request is relayed to the receiver over a streaming session = at the subdirectory identified by the hash of psk. Messages ar= e secured by symmetric cipher rather than TLS or Onion routing session key.= Sender and receiver may experience network interruption and proceed with t= he protocol since their request and response are buffered at the Payjoin re= lay subdirectory. >=20 >=20 > =3D=3D=3DPayjoin version 2 messaging=3D=3D=3D >=20 > Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/master/bip= -0370.mediawiki|BIP 370 PSBT v2]] format to fascilitate PSBT mutation. >=20 > The payjoin version 2 protocol takes the following steps: >=20 > * The recipient sends the first 4 bytes of H(psk) and option= al authentication credential according to [[#receiver-relay-enrollment|rece= iver relay enrollment]] protocol. It may go offline and replay enrollment t= o come back online. >=20 > * Out of band, the receiver of the payment, shares a bitcoin URI with the= sender including a pj=3D query parameter describing the relay= subdirectory endpoint and psk=3D parameter with base64 encode= d 256-bit secret key. To support version 1 senders the relay acts as an uns= ecured payjoin server so pjos=3D0 must be specified in the URI= . Version 2 senders may safely allow output substitution regardless. >=20 > * The sender creates a valid PSBT according to [[https://github.com/bitco= in/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiver= checklist]] formatted as PSBTv2. We call this the Fallback PSBT. This Fallback PSBT and optional sender parameters are encrypted and aut= henticated with the psk using ChaCha20Poly1305 and streamed to= the relay subdirectory endpoint. >=20 > * The sender awaits a response from the relay stream containing an encryp= ted Payjoin PSBT. It can replay the Fallback PSBT= to request a response if it goes offline. >=20 > * The request is stored in the receiver's subdirectory buffer. > * Once the receiver is online, it awaits a stream of request updates from= the relay. The receiver decrypts aund authenticates the payload then check= s it according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#re= ceivers-original-psbt-checklist|the receiver checklist]]. It updates it to = include new signed inputs and outputs invalidating sender signatures, and m= ay adjust the fee. We call this the Payjoin PSBT. >=20 > * It responds with the Payjoin PSBT encrypted then authentic= ated under psk using ChaCha20Poly1305. >=20 > * The relay awaits a connection from the sender if it goes offline. Upon = connection, it relays the encrypted Payjoin PSBT to the sender= . >=20 > * The sender validates the Payjoin PSBT according to [[#send= ers-payjoin-psbt-checklist|the sender checklist]], signs its inputs and bro= adcasts the transaction to the Bitcoin network. >=20 >=20 > The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as bytes. >=20 > The Fallback PSBT MUST: >=20 > * Include complete UTXO data. > * Be signed. > * Exclude unnecessary fields such as global xpubs or keypath information.= >=20 > * Set input and output Transaction Modifiable Flags to 1 > * Be broadcastable. >=20 > The Fallback PSBT MAY: >=20 > * Include outputs unrelated to the sender-receiver transfer for batching = purposes. > * Set SIGHASH_SINGLE Transaction Modifiable Flags flags to 1 >=20 > The Payjoin PSBT MUST: >=20 > * Include all inputs from the Fallback PSBT. > * Include all outputs which do not belong to the receiver from the Fallba= ck PSBT. > * Include complete UTXO data. >=20 > The Payjoin PSBT sender MAY: >=20 > * Add, remove or modify Fallback PSBT outputs under the control of the re= ceiver (i.e. not sender change). >=20 > The Payjoin PSBT MUST NOT: >=20 > * Shuffle the order of inputs or outputs; the additional outputs or addit= ional inputs must be inserted at a random index. > * Decrease the absolute fee of the original transaction. >=20 > =3D=3D=3DReceiver's Payjoin PSBT checklist=3D=3D=3D >=20 > Other than requiring PSBTv2 the receiver checklist is the same as the [[h= ttps://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-ori= ginal-psbt-checklist|the BIP 78 receiver checklist]] >=20 > =3D=3D=3DSender's Payjoin PSBT checklist=3D=3D=3D >=20 > The version 2 sender's checklist is largely the same as the [[https://git= hub.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-checklis= t|the BIP 78 checklist]] with the exception that it expects ALL utxo data t= o be filled in. BIP 78 required sender inputs UTXO data to be excluded from= the PSBT which has caused many headaches since it required the sender to a= dd them back to the Payjoin proposal PSBT. Version 2 has no such requiremen= t. >=20 > =3D=3D=3DRelay interactions=3D=3D=3D >=20 > The Payjoin Relay provides a rendezvous point for sender and receiver to = meet. It stores Payjoin payloads to support asynchronous communication. It = is available on the open internet over HTTPS to accept both WebTransport fo= r Payjoin version 2, accepting encrypted payloads, and optionally HTTP/1.1 = to support backwards compatible Payjoin version 1 requests. >=20 > =3D=3D=3DReceiver interactions=3D=3D=3D >=20 > =3D=3D=3D=3DRelay enrollment=3D=3D=3D=3D >=20 > Receivers must enroll to have resources allocated on a relay. Sessions ma= y begin by having a receiver send the first 4 bytes of the Sha256 hash of t= heir psk to the relay. The receiver returns the subdirectory e= ndpoint url. Enrollment may be replayed in case the receiver goes offline. >=20 >=20 > Optionally, before returning the uri the receiver may request an authenti= cation token by presenting a message containing only the word Authent= icate: after which the receiver is required to submit = an Authenticate: including the token from the Relay ou= t of band. If authentication fails an error is returned. >=20 >=20 > In the case a relay is operated by an exchange, it may give out authentic= ation tokens for users of its app, or may require some proof of work out of= band. Tokens should be anonymous credentials from the relay describing the= parameters of their authorization. Specific credentialing is out of the sc= ope of this proposal. >=20 > =3D=3D=3D=3DReceiver Payjoin PSBT response=3D=3D=3D=3D >=20 > The receiver streams the base64 Payjoin PSBT as encrypted bytes from ChaC= ha20Poly1305 under psk. >=20 >=20 > =3D=3D=3DSender interactions=3D=3D=3D >=20 > The sender starts a WebTransport session with the relay at the Payjoin en= dpoint URI provided by the receiver. It sends the following payload and awa= its a relayed response payload from the receiver. >=20 > =3D=3D=3D=3DVersion 2 Fallback PSBT request=3D=3D=3D=3D >=20 > The version 2 Fallback PSBT Payload is constructed in JSON before being e= ncrypted as follows. >=20 > 
>=20
> {
> "psbt": "",
>=20
> "params": {
> "param1": "",
>=20
> "param2": "",
>=20
> ...
> }
> }
>
>=20 >=20 > The payload must be encrypted using ChaCha20Poly1305 by the sender using = the psk. >=20 >=20 > =3D=3D=3D=3DVersion 1 Fallback PSBT request=3D=3D=3D=3D >=20 > The message should be the same as version 2 but unencrypted, as version 1= is unaware of encryption when using an unsecured payjoin server. The Relay= should convert the PSBT to PSBTv2 and construct the JSON payload from the = HTTP request body and optional query parameters. Upon receiving an unencryp= ted PSBTv2 response from a receiver, it should convert it to PSBTv0 for com= patibility with BIP 78. >=20 > =3D=3D=3DAsynchronous relay buffers=3D=3D=3D >=20 > Each receiver subdirectory on the relay server has a buffer for requests = and one for responses. Each buffer updates listeners through awaitable even= ts so that updates are immediately apparent to relevant client sessions. >=20 > =3D=3D=3DBIP 21 receiver parameters=3D=3D=3D >=20 > A major benefit of BIP 78 payjoin over other coordination mechanisms is i= ts compatibility with the universal BIP 21 bitcoin URI standard. >=20 > This proposal defines the following new [[https://github.com/bitcoin/bips= /blob/master/bip-0021.mediawiki|BIP 21 URI]] parameters: >=20 > * psk: the pre-shared symmetric key for encryption and authe= ntication with ChaCha20-Poly1305 >=20 > * exp: represents a request expiration after which the recei= ver reserves the right to broadcast the Fallback and ignore requests. >=20 >=20 > BIP 78's BIP 21 payjoin parameters are also valid for version 2. >=20 > =3D=3D=3DOptional sender parameters=3D=3D=3D >=20 > When the payjoin sender posts the original PSBT to the receiver, it can o= ptionally specify the following HTTP query string parameters: >=20 > * v: represents the version number of the payjoin protocol t= hat the sender is using. This version is 2. >=20 >=20 > BIP 78's optional query parameters are also valid as version 2 parameters= . >=20 > =3D=3DRationale=3D=3D >=20 > =3D=3D=3DRequest expiration & fallback=3D=3D=3D >=20 > The relay may hold a request for an offline payjoin peer until that peer = comes online. However, the BIP 78 spec recommends broadcasting request PSBT= s in the case of an offline counterparty. Doing so exposes a na=C3=AFve, su= rveillance-vulnerable transaction which payjoin intends to avoid. >=20 > The existing BIP 78 protocol has to be synchronous only for automated end= points which may be vulnerable to probing attacks. It can cover this tradeo= ff by demanding a fallback transaction that would not preserve privacy the = same way as a payjoin. BIP 21 URI can communicate a request expiration to a= lleviate both of these problems. Receivers may specify a deadline after whi= ch they will broadcast this fallback with a new expiration parameter = exp=3D. >=20 >=20 > =3D=3D=3DWebTransport=3D=3D=3D >=20 > Many transport protocols are good candidates for Serverless Payjoin funct= ionality, but WebTransport stands out in its ability to stream and take adv= antage of QUIC's performance in mobile environments. In developing this BIP= , serverless payjoin proofs of concept using TURN, HTTP/1.1 long polling, W= ebSockets, Magic Wormhole, and Nostr have been made. Streaming allows the r= elay to have more granular and asynchronous understanding of the state of t= he peers, and this protcol is designed specifically to address the shortcom= ings of an HTTP protocol's requirement to receive from a reliable, always-o= nline connection. >=20 > While WebTransport and HTTP/3 it is built on are relatively new, widespre= ad support across browsers assures me that it is being accepted as a standa= rd and even has a fallback to HTTP/2 environments. Being built on top of QU= IC allows it to multiplex connections from a relay to multiple peers which = may prove advantageous for later payjoin protocols between more than two pa= rticipants contributing inputs, such as those used to fund a lightning node= with channels from multiple sources in one transaction, or those with thre= at models more similar to ZeroLink CoinJoin. >=20 > While Nostr is fascinating from the perspective of censorship resistance,= the backwards compatibility with Payjoin v1 would mean only custom Nostr P= ayjoin relays exposing an https endpoint would be suitable. Nostr transport= is also limited by the performance of WebSockets, being an abstraction on = top of that protocol. If Nostr authentication were used instead of a symmet= ric psk then those keys would also need to be communicated out= of band and complicate the protocol. There is nothing stopping a new versi= on of this protocol or a NIP making Payjoin version 2 possible over Nostr s= hould Payjoin censorship become a bottleneck in the way of adoption. >=20 >=20 > WebTransport is already shipped in both Firefox, Chrome, h3 in Rust, Go, = and all popular languages. There is also [[https://w3c.github.io/p2p-webtra= nsport/|a working draft for full P2P WebTransport]] without any relay, whic= h a future payjoin protocol may make use of. >=20 > =3D=3D=3DChaCha20Poly1305 AEAD=3D=3D=3D >=20 > This authenticated encryption with additional data [[https://en.wikipedia= .org/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 and has= high performance. ChaCha20Poly1305 AEAD seems to be making its way into bi= tcoin by way of [[https://github.com/bitcoin/bips/blob/master/bip-0324.medi= awiki|BIP 324]] as well. The protocol has widespread support in browsers, O= penSSL and libsodium. AES-GCM is more widespread but is both older, slower,= and not a dependency in bitcoin software. >=20 > secp256k1 asymmetric cryptography could be used, but symmetric encryption= allows for many fewer messages to be sent, a single ephemeral key, and see= ms suitable given the one time use of BIP 21 URIs for Payjoin. Payjoin alre= ady requires base64 encoding for PSBTs, so we have it available to encode t= he 256-bit psk in the BIP 21 parameter. >=20 >=20 > =3D=3D=3DPSBT Version 2=3D=3D=3D >=20 > The PSBT version 1 protocol was replaced because it was not designed to h= ave 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.= This can cause some strange behaviors from signers who don't know where to= look to find the scripts that they are accountable for. PSBT version 2 mak= es mutating a PSBT's inputs and outputs trivial. It also eliminates the tra= nsaction finalization step. Receivers who do not understand PSBT version 1 = may choose to reject Payjoin version 1 requests and only support PSBT versi= on 2. >=20 > =3D=3D=3DAttack vectors=3D=3D=3D >=20 > Since relays store arbitrary encrypted payloads to the tragedy of the com= mons and denial of service attacks. Relay operators may impose an authentic= ation requirement before they provide relay service to receivers to mitigat= e such attacks. >=20 > Since psk is a symmetric key, the first message containing t= he sender's original PSBT does not have forward secrecy. Since relay buffer= s are associated with a single ephemeral relay directory, to support reques= t-response simplicity of version 1, this seems appropriate. >=20 >=20 > Since the Fallback PSBT is valid, even where exp=3D is speci= fied, the receiver may broadcast it and lose out on ambiguous privacy prote= ction from payjoin at any time. Though unfortunate, this is the typical bit= coin transaction flow today anyhow. >=20 >=20 > =3D=3D=3DNetwork privacy=3D=3D=3D >=20 > Unlike BIP 78 implementations, sender and receiver peers will only see th= e IP address of the relay, not their peer's. Relays may be made available v= ia Tor hidden service or Oblivious HTTP in addition to IP / DNS to allow ei= ther of the peers to protect their IP from the relay with without requiring= both peers to use additional network security dependencies. >=20 > =3D=3DBackwards compatibility=3D=3D >=20 > The receivers advertise payjoin capabilities through [[https://github.com= /bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]]. >=20 > Senders not supporting payjoin will just ignore the pj=3D pa= rameter and proceed to typical address-based transaction flows. req-p= j=3D may be used to compel payjoin. >=20 >=20 > Receivers may choose to support version 1 payloads. Version 2 payjoin URI= s should enable pjos=3D0 so that these v1 senders disable outp= ut substitution since the v1 messages are neither encrypted nor authenticat= ed, putting them at risk for man-in-the-middle attacks otherwise. The relay= protocol should carry on as normal, validating based on HTTP headers and c= onstructing an unencrypted Version 2 payload from optional query parameters= , and PSBT in the body. >=20 >=20 > The BIP 78 error messages are already JSON formatted, so it made sense to= rely on the same dependency for these payloads and error messages. >=20 > =3D=3DReference implementation=3D=3D >=20 > An early proof of concept draft reference implementation can be found at = https://github.com/payjoin/rust-payjoin/pull/78. It implements an asynchron= ous payment flow using WebSockets using PSBTv1 without encryption. Another = reference can be found at https://github.com/payjoin/rust-payjoin/pull/21 w= hich uses HTTP long polling for transport and Noise NNpsk0 for crypto. Rece= ntly, I've come to realize the rationale for WebTransport, PSBTv2, and ChaC= ha20-Poly1305 AEAD substitutions and am working on an implementation includ= ing this exact specification, but wanted to get early feedback on this desi= gn in the spirit of BIP 2. >=20 > =3D=3DAcknowledgements=3D=3D >=20 > Thank you to OpenSats for funding this pursuit, to Human Rights Foundatio= n 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 Dor= ier, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, Mike S= chmidt, Murch, D=C3=A1vid Moln=C3=A1r, Lucas Ontiviero, and uncountable twi= tter 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= the "All About BIPS" zine which I've referenced a number of times in the d= rafting process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for= hacking on the first iOS Payjoin receiver and uncovering the problem that = this solves in the first place. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev