From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4E69DC0032 for ; Fri, 11 Aug 2023 17:13:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 1356840567 for ; Fri, 11 Aug 2023 17:13:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1356840567 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=ShZs7WRo X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 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, 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 aw5hNNcvQc2G for ; Fri, 11 Aug 2023 17:13:16 +0000 (UTC) X-Greylist: delayed 601 seconds by postgrey-1.37 at util1.osuosl.org; Fri, 11 Aug 2023 17:13:16 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5C93240186 Received: from mail-4327.protonmail.ch (mail-4327.protonmail.ch [185.70.43.27]) by smtp2.osuosl.org (Postfix) with ESMTPS id 5C93240186 for ; Fri, 11 Aug 2023 17:13:16 +0000 (UTC) Date: Fri, 11 Aug 2023 17:03:02 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev header.b="ShZs7WRo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ngould.dev; s=protonmail; t=1691773391; x=1692032591; bh=lRF6pvpV7Klr7wCBY4/P5qWvvbMvnf9NhhxtM8z9c7U=; 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=ShZs7WRoeZ+qgPZ8gdq9yeowvn+MDjQxaUAF/h52/k4iMCzS2zoOy4l62MHeWsHhp dcYt2S+/k85SlWqeQseQIUq5CrqdJpem2Xk7kqtIRlQEN5FOhXbJ1sozn3rCFi0NUj oknKASaAkxXFt6mtvj6hBDEJbwgl3FZ4ytuJ1bjQ= To: bitcoin-dev@lists.linuxfoundation.org, AdamISZ From: Dan Gould Message-ID: <50A19B79-46A1-4F21-AA53-74356F4B0CBA@ngould.dev> In-Reply-To: References: 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: Fri, 11 Aug 2023 21:37:12 +0000 Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin (AdamISZ) 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: Fri, 11 Aug 2023 17:13:19 -0000 Hi waxwing thanks for the detailed response. You've identified a number of flaws both = in the protocol and the document that can be fixed. I sincerely appreciate = it. If more comes to mind, fire away. > I wanted to immediately "nit" a point I saw as I was reading: >=20 >> Because BIP 78 messages are neither authenticated nor encrypted a malici= ous unsecured payjoin server is able to modify the Payjoin PSBT in flight, >=20 > Taken as is - i.e. out of context! - this is just wrong. The BIP explicit= ly states: >=20 > "The sender must ensure that the url refers to a scheme or protocol using= authenticated encryption, for example TLS with certificate validation, or = a .onion link to a hidden service whose public key identifier has already b= een communicated via a TLS connection. Senders SHOULD NOT accept a url repr= esenting an unencrypted or unauthenticated connection. " Nice Catch. I've fixed it in the draft. > 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 obscu= ring the question of securely sharing the secret key? Did you consider DH-i= ng this as other protocols do? At the very least I would claim that it's li= kely that implementers might be sloppy here; at the most I would claim this= is just insecure full stop. At first I thought this would be secure because the relay itself would need= to discover the key only to uncover privacy, but because of output substit= ution it would actually open the protocol to a loss of funds attack: If the= ask-containing bip21 were discovered by the relay, then the relay would ha= ve enough information to both find the buffer and forge a Payjoin PSBT payi= ng itself rather than the receiver, and the sender would send it because ou= tput substitution is allowed. Even though I handle bip21s and addresses as = secret, I know many people post them in unencrypted channels and so they sh= ould not be assumed secure to pass secrets. I have certainly considered the security trade offs of using a symmetric ke= y vs DH. The main reason I chose to use the symmetric psk over DH is becaus= e I thought DH would require another round of communication to establish re= ceiver authentication, which is a huge inconvenience in an asynchronous set= ting. The attack I=E2=80=99ve described can be mitigated inside the same me= ssage pattern by having receiver share a public key of a per-request keypai= r Instead, approximately following the NKpsk0 pattern, the sender may pass = an ephemeral secret session key under which the Payjoin PSBT response would= be encrypted and authenticated so no malicious adversary with knowledge of= the bip21 would be unable to read or forge. Stowaway uses BIP 47 codes for= this purpose, but I see no reason to tie buffer identity to the underlying= wallet. Using ephemeral keys also allows a single receiver to enroll multi= ple buffers at a relay simultaneously. > About attack vectors: >=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 > Isn't the most obvious concern with this architecture, that the relays ha= ve metadata - most obviously, they can time correlate messages, with bitcoi= n network events, so at the least they could tie transactions to clients. *= If* both parties use anonymised network connections then this is ameliorate= d (though not removed) as a vector, but then we'd need to be clear that we = *require* those (e.g. Tor). Not sure if it's palatable to do this if otherw= ise, i.e. if we think the relays can tie network addresses to transactions?= Well, not sure, but I'd expect it to be mentioned? The most obvious concern with this architecture is indeed that the relays w= ould have metadata that could be used for timing attacks correlating to a P= ayjoin PSBT buffer being cleared from the relay and a potential payjoin tra= nsaction being broadcast. If a sufficient number of steganographic transact= ions are broadcast per quantum, then requiring a sender to broadcast only a= fter a random delay based on a poisson distribution could mitigate this pro= blem somewhat. According to S. Ghesmati 2020 research, between 27% and 42% = of all transactions conform to the type of unnecessary input heuristic that= payjoins conform to (UIH2). So it wouldn=E2=80=99t take long for multiple = steganographic candidates to enter the Mempool at any given time. I'm extremely reluctant to require Tor because it severely limits the numbe= r of environments where this proposal could be deployed. If we were to requ= ire Tor, we should then just ignore this proposal and focus on deploying hi= dden service based v1 receivers as in JoinMarket. I'm more inclined to requ= ire Oblivious HTTP but even that seems overkill when the threat would be fo= r the relay to correlate steganographic transactions, which don't have a si= ngle clear sender/receiver interpretation, to two ip addresses. > It just occurred to me that while timing correlation itself might not be = much (in usual circumstances, there are tons of other transactions), it's, = as usual with metadata, the intersection of more than one thing that could = hurt: I know when the tx happens (say within a time window of 10 seconds), = but also I might know the *size* of the message. Perhaps consider random pa= dding of the Payjoin PSBT message size (iirc chacha is a stream cipher so l= engths are arbitrary). The biggest intersection attack is timing correlation of two linked potenti= al payjoin transactions related to one IP address. Again, a specified delay= may help mitigate this concern. I agree that padding ought to be a requirement. 4M block size limit with ba= se64 encoding overhead seems like a resonable buffer size, but PSBTs have s= ignificant overhead compared to consensus transactions, so the exact size o= f a buffer needs more attention. Thanks for the feedback, Dan > On Aug 10, 2023, at 12:21 PM, wrote: >=20 > Send bitcoin-dev mailing list submissions to > bitcoin-dev@lists.linuxfoundation.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > or, via email, send a message with subject or body 'help' to > bitcoin-dev-request@lists.linuxfoundation.org >=20 > You can reach the person managing the list at > bitcoin-dev-owner@lists.linuxfoundation.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bitcoin-dev digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: BIP for Serverless Payjoin (AdamISZ) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Thu, 10 Aug 2023 15:46:18 +0000 > From: AdamISZ > To: Dan Gould , Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin > Message-ID: > >=20 > Content-Type: text/plain; charset=3Dutf-8 >=20 > Sorry for yet another message but: >=20 > It just occurred to me that while timing correlation itself might not be = much (in usual circumstances, there are tons of other transactions), it's, = as usual with metadata, the intersection of more than one thing that could = hurt: I know when the tx happens (say within a time window of 10 seconds), = but also I might know the *size* of the message. Perhaps consider random pa= dding of the Payjoin PSBT message size (iirc chacha is a stream cipher so l= engths are arbitrary). >=20 > Cheers, > AdamISZ/waxwing >=20 >> Isn't the most obvious concern with this architecture, that the relays h= ave metadata - most obviously, they can time correlate messages, with bitco= in 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 otherwise= , i.e. if we think the relays can tie network addresses to transactions? We= ll, not sure, but I'd expect it to be mentioned? >>=20 >> Cheers, >> AdamISZ/waxwing >>=20 >>=20 >> Sent with Proton Mail secure email. >>=20 >>=20 >> ------- Original Message ------- >> On Wednesday, August 9th, 2023 at 11:32, Dan Gould via bitcoin-dev bitco= in-dev@lists.linuxfoundation.org wrote: >>=20 >>=20 >>=20 >>> Hi all, >>>=20 >>> The Serverless Payjoin idea has come a long way toward formal specifica= tion of a Payjoin version 2. In the spirit of BIP 2, I?m sharing an interme= diate draft of the BIP here before opening a draft on GitHub for the BIP ed= itors, and before this exact specification has a complete reference impleme= ntation. The draft does reference two proof of concept payjoin implementati= ons, one demonstrating use of symmetric cryptography, and the other asynchr= onous messaging and backwards compatibility. >>>=20 >>> I?ve updated the Serverless Payjoin gist to reflect this draft specific= ation https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9 in = order to preserve the edit history before opening a bips PR. >>>=20 >>> The specifics have changed significantly compared to the first mailing = list 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 >>> =3D=3DAbstract=3D=3D >>>=20 >>> This document proposes a backwards-compatible second version of the pay= join protocol described in [[bip-0078.mediawiki|BIP 78]], allowing complete= payjoin receiver functionality including payment output substitution witho= ut requiring them to host a secure public endpoint. This requirement is rep= laced with an untrusted third-party relay and streaming clients which commu= nicate 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,= that transactions with multiple inputs "necessarily reveal that their inpu= ts were owned by the same owner." Breaking that common-input ownership assu= mption and others requires input from multiple owners. Cooperative transact= ion construction also increases transaction throughput by providing new opp= ortunity for payment batching and transaction cut-through. >>>=20 >>> Version 1 coordinates payjoins over a public server endpoint secured by= either TLS or Tor onion hidden service hosted by the receiver. Version 1 i= s synchronous, so both sender and reciever must be online simultaneously to= payjoin. Both requirements present significant barriers for all but sophis= ticated server operators or those wallets with complex Tor integration. The= se barriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2= 021-January/018358.html|regarded]] as limits to payjoin adoption. >>>=20 >>> The primary goal of this proposal is to provide a practical coordinatio= n mechanism to be adopted in a vast majority of wallet environments. This i= s realized as a simple protocol built on bitcoin URI requests, web standard= s, 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 whi= le being encapsulated in authenticated encryption, forgoing HTTP messaging = for WebTransport streaming of asynchronus interactions, and leveraging PSBT= version 2. >>>=20 >>> The BIP 78 standard allows for an [[https://github.com/bitcoin/bips/blo= b/master/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin serv= er|]] to operate separately from the so-called "payment server" responsible= for generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.medi= awiki|BIP 21]] request URIs. Because BIP 78 messages are neither authentica= ted nor encrypted a malicious unsecured payjoin server is able to modify th= e Payjoin PSBT in flight, thus requiring [[payment output substitition]] to= be disabled. Output substitition is useful for a number of block space opt= imizations, including payment batching and transaction cut-through. This pr= oposal introduces authentication and encryption to secure output substition= while using a relay without compromising sender or receiver privacy. >>>=20 >>> Although unsecured payjoin server separation is mentioned in BIP 78, no= known specification or implementation of one exists. This document specifi= es one to be backwards compatible with version 1 senders. Receivers respond= ing to version 1 senders must disable output substitution their payloads ar= e plaintext so they may payjoin without the risk of the relay stealing fund= s. >>>=20 >>> The protocols in this document reuse BIP 78's BIP 21 URI parameters. A = Fallback PSBT timeout parameter is introduced which may also help coordinat= e 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/ST= OWAWAY.md|Stowaway]] is a payjoin coordination mechanism which depends on T= or, 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. T= he payjoin version 2 protocol uses one-time symmetric keys for relay subdir= ectory identification, authentication, and encryption instead of BIP 47 pub= lic keys derived from the wallet. Payjoin version 2 also supports asynchron= ous messaging, in contrast to online Stowaway's synchronous HTTP-based mess= aging. Offline stowaway may depends on manual message passing rather than a= n asynchronous network protocol. Successful Stowaway execution results in 2= -output transactions, while BIP 79, 78, and this work may produce batched t= ransactions 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 publ= ic HTTP endpoint, this scheme allows a WebTransport client to enroll with a= relay server to receive payjoin. Relays may optionally require an authoriz= ation credential before allocating resources in order to prevent DoS attack= s. Sender and receiver payloads are buffered at the relay to support asynch= ronous interaction. Symmetric authenticated encryption (ChaCha20-Poly1305 A= EAD) prevents the relay from snooping on message contents or forging messag= es. Aside from a pre-shared secret and relayed asynchronus networking, the = version 2 messaging takes much the same form as the existing BIP 78 specifi= cation. >>>=20 >>> =3D=3D=3DBasic scheme=3D=3D=3D >>>=20 >>> The recipient first generates a 256-bit key psk. This pre-= shared key will be the basis of end-to-end authenticated encryption and ide= ntification of a particular payjoin over the relay. >>>=20 >>> Rather than hosting a public server, they start a streaming session to = receive messages and allocate a subdirectory from which to relay messages. = The first message must include the first 4 bytes of the Sha256 hash of thei= r psk to be enrolled as a subdirectory identifier. The next me= ssage streamed from the relay to sender includes the enrolled subdirectory = payjoin endpoint. After enrollment, they await a payjoin request on a sessi= on identified by the subdirectory. Out of band, the receiver shares a [[htt= ps://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] payjoi= n uri including the relay endpoint in the pj=3D query paramete= r and the pre-shared key in a new psk=3D query parameter. >>>=20 >>> The sender constructs an encrypted and authenticated payload containing= a PSBT and optional parameters similar to BIP 78. The resulting ciphertext= ensures message secrecy and integrity when streamed to the recipient by th= e relay-hosted subdirectory pj=3D endpoint. >>>=20 >>> The sender's request is relayed to the receiver over a streaming sessio= n at the subdirectory identified by the hash of psk. Messages = are secured by symmetric cipher rather than TLS or Onion routing session ke= y. Sender and receiver may experience network interruption and proceed with= the protocol since their request and response are buffered at the Payjoin = relay subdirectory. >>>=20 >>> =3D=3D=3DPayjoin version 2 messaging=3D=3D=3D >>>=20 >>> Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/master/b= ip-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 opti= onal authentication credential according to [[#receiver-relay-enrollment|re= ceiver relay enrollment]] protocol. It may go offline and replay enrollment= to come back online. >>>=20 >>> * Out of band, the receiver of the payment, shares a bitcoin URI with t= he sender including a pj=3D query parameter describing the rel= ay subdirectory endpoint and psk=3D parameter with base64 enco= ded 256-bit secret key. To support version 1 senders the relay acts as an u= nsecured payjoin server so pjos=3D0 must be specified in the U= RI. Version 2 senders may safely allow output substitution regardless. >>>=20 >>> * The sender creates a valid PSBT according to [[https://github.com/bit= coin/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiv= er checklist]] formatted as PSBTv2. We call this the Fallback PSBT. This Fallback PSBT and optional sender parameters are encrypted and a= uthenticated with the psk using ChaCha20Poly1305 and streamed = to the relay subdirectory endpoint. >>>=20 >>> * The sender awaits a response from the relay stream containing an encr= ypted 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 fr= om the relay. The receiver decrypts aund authenticates the payload then che= cks it according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#= receivers-original-psbt-checklist|the receiver checklist]]. It updates it t= o include new signed inputs and outputs invalidating sender signatures, and= may adjust the fee. We call this the Payjoin PSBT. >>>=20 >>> * It responds with the Payjoin PSBT encrypted then authent= icated under psk using ChaCha20Poly1305. >>>=20 >>> * The relay awaits a connection from the sender if it goes offline. Upo= n connection, it relays the encrypted Payjoin PSBT to the send= er. >>>=20 >>> * The sender validates the Payjoin PSBT according to [[#se= nders-payjoin-psbt-checklist|the sender checklist]], signs its inputs and b= roadcasts the transaction to the Bitcoin network. >>>=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 informatio= n. >>>=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 batchin= g 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 Fall= back PSBT. >>> * Include complete UTXO data. >>>=20 >>> The Payjoin PSBT sender MAY: >>>=20 >>> * Add, remove or modify Fallback PSBT outputs under the control of the = receiver (i.e. not sender change). >>>=20 >>> The Payjoin PSBT MUST NOT: >>>=20 >>> * Shuffle the order of inputs or outputs; the additional outputs or add= itional 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 [= [https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-o= riginal-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://g= ithub.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-checkl= ist|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 fr= om the 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 requirem= ent. >>>=20 >>> =3D=3D=3DRelay interactions=3D=3D=3D >>>=20 >>> The Payjoin Relay provides a rendezvous point for sender and receiver t= o meet. It stores Payjoin payloads to support asynchronous communication. I= t 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. >>>=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 = may begin by having a receiver send the first 4 bytes of the Sha256 hash of= their psk to the relay. The receiver returns the subdirectory= endpoint url. Enrollment may be replayed in case the receiver goes offline= . >>>=20 >>> Optionally, before returning the uri the receiver may request an authen= tication token by presenting a message containing only the word Authe= nticate: after which the receiver is required to submi= t an Authenticate: including the token from the Relay = out of band. If authentication fails an error is returned. >>>=20 >>> In the case a relay is operated by an exchange, it may give out authent= ication 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 t= he parameters of their authorization. Specific credentialing is out of the = scope 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 Ch= aCha20Poly1305 under psk. >>>=20 >>> =3D=3D=3DSender interactions=3D=3D=3D >>>=20 >>> The sender starts a WebTransport session with the relay at the Payjoin = endpoint URI provided by the receiver. It sends the following payload and a= waits 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= encrypted as follows. >>>=20 >>> 
>>>=20
>>> {
>>> "psbt": "",
>>>=20
>>> "params": {
>>> "param1": "",
>>>=20
>>> "param2": "",
>>>=20
>>> ...
>>> }
>>> }
>>>
>>>=20 >>> The payload must be encrypted using ChaCha20Poly1305 by the sender usin= g the psk. >>>=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 Rel= ay should convert the PSBT to PSBTv2 and construct the JSON payload from th= e HTTP request body and optional query parameters. Upon receiving an unencr= ypted PSBTv2 response from a receiver, it should convert it to PSBTv0 for c= ompatibility with BIP 78. >>>=20 >>> =3D=3D=3DAsynchronous relay buffers=3D=3D=3D >>>=20 >>> Each receiver subdirectory on the relay server has a buffer for request= s and one for responses. Each buffer updates listeners through awaitable ev= ents 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= its compatibility with the universal BIP 21 bitcoin URI standard. >>>=20 >>> This proposal defines the following new [[https://github.com/bitcoin/bi= ps/blob/master/bip-0021.mediawiki|BIP 21 URI]] parameters: >>>=20 >>> * psk: the pre-shared symmetric key for encryption and aut= hentication with ChaCha20-Poly1305 >>>=20 >>> * exp: represents a request expiration after which the rec= eiver reserves the right to broadcast the Fallback and ignore requests. >>>=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= optionally specify the following HTTP query string parameters: >>>=20 >>> * v: represents the version number of the payjoin protocol= that the sender is using. This version is 2. >>>=20 >>> BIP 78's optional query parameters are also valid as version 2 paramete= rs. >>>=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 pee= r comes online. However, the BIP 78 spec recommends broadcasting request PS= BTs in the case of an offline counterparty. Doing so exposes a na?ve, surve= illance-vulnerable transaction which payjoin intends to avoid. >>>=20 >>> The existing BIP 78 protocol has to be synchronous only for automated e= ndpoints which may be vulnerable to probing attacks. It can cover this trad= eoff by demanding a fallback transaction that would not preserve privacy th= e same way as a payjoin. BIP 21 URI can communicate a request expiration to= alleviate both of these problems. Receivers may specify a deadline after w= hich they will broadcast this fallback with a new expiration parameter exp=3D. >>>=20 >>> =3D=3D=3DWebTransport=3D=3D=3D >>>=20 >>> Many transport protocols are good candidates for Serverless Payjoin fun= ctionality, but WebTransport stands out in its ability to stream and take a= dvantage of QUIC's performance in mobile environments. In developing this B= IP, serverless payjoin proofs of concept using TURN, HTTP/1.1 long polling,= WebSockets, Magic Wormhole, and Nostr have been made. Streaming allows the= relay to have more granular and asynchronous understanding of the state of= the peers, and this protcol is designed specifically to address the shortc= omings of an HTTP protocol's requirement to receive from a reliable, always= -online connection. >>>=20 >>> While WebTransport and HTTP/3 it is built on are relatively new, widesp= read support across browsers assures me that it is being accepted as a stan= dard 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 whic= h may prove advantageous for later payjoin protocols between more than two = participants contributing inputs, such as those used to fund a lightning no= de with channels from multiple sources in one transaction, or those with th= reat models more similar to ZeroLink CoinJoin. >>>=20 >>> While Nostr is fascinating from the perspective of censorship resistanc= e, the backwards compatibility with Payjoin v1 would mean only custom Nostr= Payjoin relays exposing an https endpoint would be suitable. Nostr transpo= rt is also limited by the performance of WebSockets, being an abstraction o= n top of that protocol. If Nostr authentication were used instead of a symm= etric psk then those keys would also need to be communicated o= ut of band and complicate the protocol. There is nothing stopping a new ver= sion of this protocol or a NIP making Payjoin version 2 possible over Nostr= should Payjoin censorship become a bottleneck in the way of adoption. >>>=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-webt= ransport/|a working draft for full P2P WebTransport]] without any relay, wh= ich 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.wikiped= ia.org/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 and h= as high performance. ChaCha20Poly1305 AEAD seems to be making its way into = bitcoin by way of [[https://github.com/bitcoin/bips/blob/master/bip-0324.me= diawiki|BIP 324]] as well. The protocol has widespread support in browsers,= OpenSSL and libsodium. AES-GCM is more widespread but is both older, slowe= r, and not a dependency in bitcoin software. >>>=20 >>> secp256k1 asymmetric cryptography could be used, but symmetric encrypti= on allows for many fewer messages to be sent, a single ephemeral key, and s= eems suitable given the one time use of BIP 21 URIs for Payjoin. Payjoin al= ready requires base64 encoding for PSBTs, so we have it available to encode= the 256-bit psk in the BIP 21 parameter. >>>=20 >>> =3D=3D=3DPSBT Version 2=3D=3D=3D >>>=20 >>> The PSBT version 1 protocol was replaced because it was not designed to= have inputs and outputs be mutated. Payjoin mutates the PSBT, so BIP 78 us= es a hack where a new PSBT is created by the receiver instead of mutating i= t. 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 m= akes mutating a PSBT's inputs and outputs trivial. It also eliminates the t= ransaction finalization step. Receivers who do not understand PSBT version = 1 may choose to reject Payjoin version 1 requests and only support PSBT ver= sion 2. >>>=20 >>> =3D=3D=3DAttack vectors=3D=3D=3D >>>=20 >>> Since relays store arbitrary encrypted payloads to the tragedy of the c= ommons and denial of service attacks. Relay operators may impose an authent= ication requirement before they provide relay service to receivers to mitig= ate such attacks. >>>=20 >>> Since psk is a symmetric key, the first message containing= the sender's original PSBT does not have forward secrecy. Since relay buff= ers are associated with a single ephemeral relay directory, to support requ= est-response simplicity of version 1, this seems appropriate. >>>=20 >>> Since the Fallback PSBT is valid, even where exp=3D is spe= cified, the receiver may broadcast it and lose out on ambiguous privacy pro= tection from payjoin at any time. Though unfortunate, this is the typical b= itcoin transaction flow today anyhow. >>>=20 >>> =3D=3D=3DNetwork privacy=3D=3D=3D >>>=20 >>> 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 = either of the peers to protect their IP from the relay with without requiri= ng both peers to use additional network security dependencies. >>>=20 >>> =3D=3DBackwards compatibility=3D=3D >>>=20 >>> The receivers advertise payjoin capabilities through [[https://github.c= om/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]]. >>>=20 >>> Senders not supporting payjoin will just ignore the pj=3D = parameter 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 U= RIs should enable pjos=3D0 so that these v1 senders disable ou= tput substitution since the v1 messages are neither encrypted nor authentic= ated, putting them at risk for man-in-the-middle attacks otherwise. The rel= ay protocol should carry on as normal, validating based on HTTP headers and= constructing an unencrypted Version 2 payload from optional query paramete= rs, and PSBT in the body. >>>=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 a= t https://github.com/payjoin/rust-payjoin/pull/78. It implements an asynchr= onous payment flow using WebSockets using PSBTv1 without encryption. Anothe= r reference can be found at https://github.com/payjoin/rust-payjoin/pull/21= which uses HTTP long polling for transport and Noise NNpsk0 for crypto. Re= cently, I've come to realize the rationale for WebTransport, PSBTv2, and Ch= aCha20-Poly1305 AEAD substitutions and am working on an implementation incl= uding this exact specification, but wanted to get early feedback on this de= sign in the spirit of BIP 2. >>>=20 >>> =3D=3DAcknowledgements=3D=3D >>>=20 >>> Thank you to OpenSats for funding this pursuit, to Human Rights Foundat= ion for putting a bounty on it and funding invaluable BOB Space space suppo= rt, who I owe a thank you to as well. Thank you to Ethan Heilman, Nicolas D= orier, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, Mike= Schmidt, Murch, D?vid Moln?r, Lucas Ontiviero, and uncountable twitter ple= bs 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 "Al= l About BIPS" zine which I've referenced a number of times in the drafting = process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for hacking= on the first iOS Payjoin receiver and uncovering the problem that this sol= ves in the first place. >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 >=20 > ------------------------------ >=20 > End of bitcoin-dev Digest, Vol 99, Issue 25 > *******************************************