diff options
| author | symphonicbtc <symphonicbtc@proton.me> | 2023-08-11 22:04:23 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-08-11 22:04:44 +0000 |
| commit | 700837c9a9886b148393612a11b5c9a59be28cb8 (patch) | |
| tree | dab8ea1f0e1e099f4b664418b1255af29ba8e8ff /62/1c6c89db85bc70d9773da9db2667c24822e9be | |
| parent | 088693671a203aa08e4270f2b51bfd05bb06c3c8 (diff) | |
| download | pi-bitcoindev-700837c9a9886b148393612a11b5c9a59be28cb8.tar.gz pi-bitcoindev-700837c9a9886b148393612a11b5c9a59be28cb8.zip | |
Re: [bitcoin-dev] BIP for Serverless Payjoin (AdamISZ)
Diffstat (limited to '62/1c6c89db85bc70d9773da9db2667c24822e9be')
| -rw-r--r-- | 62/1c6c89db85bc70d9773da9db2667c24822e9be | 823 |
1 files changed, 823 insertions, 0 deletions
diff --git a/62/1c6c89db85bc70d9773da9db2667c24822e9be b/62/1c6c89db85bc70d9773da9db2667c24822e9be new file mode 100644 index 000000000..9e75318e6 --- /dev/null +++ b/62/1c6c89db85bc70d9773da9db2667c24822e9be @@ -0,0 +1,823 @@ +Return-Path: <symphonicbtc@proton.me> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 8DE29C0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Aug 2023 22:04:44 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 67275402D4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Aug 2023 22:04:44 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 67275402D4 +Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key, + unprotected) header.d=proton.me header.i=@proton.me header.a=rsa-sha256 + header.s=ngdhkcn6pfaq7fyoevuw52crhq.protonmail header.b=aThz0tom +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 zNuGezDVLn3o + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Aug 2023 22:04:41 +0000 (UTC) +Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch + [185.70.41.104]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 831FF40169 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Aug 2023 22:04:39 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 831FF40169 +Date: Fri, 11 Aug 2023 22:04:23 +0000 +Authentication-Results: mail-41104.protonmail.ch; + dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me + header.b="aThz0tom" +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; + s=ngdhkcn6pfaq7fyoevuw52crhq.protonmail; t=1691791466; x=1692050666; + bh=qOD4tNwZonpIfzv/Mt6nkKw7EvqSzVz65042harKvvo=; + h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: + Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: + Message-ID:BIMI-Selector; + b=aThz0tomJ+Y2bNakk+TEKFMfsWgZ9YxQ0Wydbqc1VuPSTYm6sj1re0qMotSKGesjw + LJCi4zaTMA5YLjap+AoAUJ5vPl3d9KljGlWADQFo4dXrIY/K3kZjcXDaptU+2NyH5Y + gd1TqJ5P8AtqDYDGzMmdr1LM//B/Mfu8fo+ay+kU6vdD02afGgYWLmY41R8uWqYxJD + tjcEduqzmlclG323DaM1Vb526p3aqW35wIDFmKLhDKvZeV6/PVL/FT0ABz13iVp0qF + eseiz31kAHsdj8yCROcwB4Q2l0ez57br2/NHW0dTU7F9QGyClLs0vWYVA2AsZJKoBa + 7Jg7wIWtujisQ== +To: Dan Gould <d@ngould.dev> +From: symphonicbtc <symphonicbtc@proton.me> +Message-ID: <P1bXSK5FgAsqtckOyZmQ4U6XyKJavBuDC92FgE_R4osiQJIIEDndFRPBFJsU6vO0fhioctnDV9MKp1sYoCfSwswUbFfkglxHEvYaNMo67fI=@proton.me> +In-Reply-To: <50A19B79-46A1-4F21-AA53-74356F4B0CBA@ngould.dev> +References: <mailman.130337.1691684480.956.bitcoin-dev@lists.linuxfoundation.org> + <50A19B79-46A1-4F21-AA53-74356F4B0CBA@ngould.dev> +Feedback-ID: 77757318: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 22:28:51 +0000 +Cc: bitcoin-dev@lists.linuxfoundation.org +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 11 Aug 2023 22:04:44 -0000 + +Hey Dan, + +Very interested in such a protocol finally becoming standardized. Quick lit= +tle nit I noticed as well, are you sure base64 encoding is the best choice = +for the psk in the URI? You may find that having to urlencode the special c= +haracters in base64 it impacts readability and adds a layer of complexity i= +f a human wanted to extract the psk from the URI for some reason. I suggest= + using something like [base64url](https://datatracker.ietf.org/doc/html/rfc= +4648#section-5) which modifies base64 slightly to be more suited to this pu= +rpose. + +Symphonic + +------- Original Message ------- +On Friday, August 11th, 2023 at 5:03 PM, Dan Gould via bitcoin-dev <bitcoin= +-dev@lists.linuxfoundation.org> wrote: + + +> Hi waxwing +>=20 +> thanks for the detailed response. You've identified a number of flaws bot= +h in the protocol and the document that can be fixed. I sincerely appreciat= +e it. If more comes to mind, fire away. +>=20 +> > I wanted to immediately "nit" a point I saw as I was reading: +> >=20 +> > > Because BIP 78 messages are neither authenticated nor encrypted a mal= +icious unsecured payjoin server is able to modify the Payjoin PSBT in fligh= +t, +> >=20 +> > Taken as is - i.e. out of context! - this is just wrong. The BIP explic= +itly states: +> >=20 +> > "The sender must ensure that the url refers to a scheme or protocol usi= +ng authenticated encryption, for example TLS with certificate validation, o= +r a .onion link to a hidden service whose public key identifier has already= + been communicated via a TLS connection. Senders SHOULD NOT accept a url re= +presenting an unencrypted or unauthenticated connection. " +>=20 +>=20 +> Nice Catch. I've fixed it in the draft. +>=20 +> > Out of band, the receiver of the payment, shares a bitcoin URI with the= + sender including a <code>pj=3D</code> query parameter describing the relay= + subdirectory endpoint and <code>psk=3D</code> parameter with base64 encode= +d 256-bit secret key. +>=20 +> > You're sending the symmetric secret key out of band; but isn't this obs= +curing 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 = +likely that implementers might be sloppy here; at the most I would claim th= +is is just insecure full stop. +>=20 +>=20 +> At first I thought this would be secure because the relay itself would ne= +ed to discover the key only to uncover privacy, but because of output subst= +itution it would actually open the protocol to a loss of funds attack: If t= +he ask-containing bip21 were discovered by the relay, then the relay would = +have enough information to both find the buffer and forge a Payjoin PSBT pa= +ying itself rather than the receiver, and the sender would send it because = +output substitution is allowed. Even though I handle bip21s and addresses a= +s secret, I know many people post them in unencrypted channels and so they = +should not be assumed secure to pass secrets. +>=20 +> I have certainly considered the security trade offs of using a symmetric = +key vs DH. The main reason I chose to use the symmetric psk over DH is beca= +use I thought DH would require another round of communication to establish = +receiver authentication, which is a huge inconvenience in an asynchronous s= +etting. The attack I=E2=80=99ve described can be mitigated inside the same = +message pattern by having receiver share a public key of a per-request keyp= +air Instead, approximately following the NKpsk0 pattern, the sender may pas= +s an ephemeral secret session key under which the Payjoin PSBT response wou= +ld 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 f= +or this purpose, but I see no reason to tie buffer identity to the underlyi= +ng wallet. Using ephemeral keys also allows a single receiver to enroll mul= +tiple buffers at a relay simultaneously. +>=20 +> > About attack vectors: +> >=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 +> > Isn't the most obvious concern with this architecture, that the relays = +have metadata - most obviously, they can time correlate messages, with bitc= +oin 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 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? +>=20 +>=20 +> The most obvious concern with this architecture is indeed that the relays= + would have metadata that could be used for timing attacks correlating to a= + Payjoin PSBT buffer being cleared from the relay and a potential payjoin t= +ransaction being broadcast. If a sufficient number of steganographic transa= +ctions are broadcast per quantum, then requiring a sender to broadcast only= + after a random delay based on a poisson distribution could mitigate this p= +roblem somewhat. According to S. Ghesmati 2020 research, between 27% and 42= +% of all transactions conform to the type of unnecessary input heuristic th= +at payjoins conform to (UIH2). So it wouldn=E2=80=99t take long for multipl= +e steganographic candidates to enter the Mempool at any given time. +>=20 +> I'm extremely reluctant to require Tor because it severely limits the num= +ber of environments where this proposal could be deployed. If we were to re= +quire Tor, we should then just ignore this proposal and focus on deploying = +hidden service based v1 receivers as in JoinMarket. I'm more inclined to re= +quire Oblivious HTTP but even that seems overkill when the threat would be = +for the relay to correlate steganographic transactions, which don't have a = +single clear sender/receiver interpretation, to two ip addresses. +>=20 +> > It just occurred to me that while timing correlation itself might not b= +e much (in usual circumstances, there are tons of other transactions), it's= +, as usual with metadata, the intersection of more than one thing that coul= +d 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 +>=20 +> The biggest intersection attack is timing correlation of two linked poten= +tial payjoin transactions related to one IP address. Again, a specified del= +ay may help mitigate this concern. +>=20 +> I agree that padding ought to be a requirement. 4M block size limit with = +base64 encoding overhead seems like a resonable buffer size, but PSBTs have= + significant overhead compared to consensus transactions, so the exact size= + of a buffer needs more attention. +>=20 +> Thanks for the feedback, +> Dan +>=20 +> > On Aug 10, 2023, at 12:21 PM, bitcoin-dev-request@lists.linuxfoundation= +.org bitcoin-dev-request@lists.linuxfoundation.org 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 +> > Today's Topics: +> >=20 +> > 1. Re: BIP for Serverless Payjoin (AdamISZ) +> >=20 +> > ---------------------------------------------------------------------- +> >=20 +> > Message: 1 +> > Date: Thu, 10 Aug 2023 15:46:18 +0000 +> > From: AdamISZ AdamISZ@protonmail.com +> > To: Dan Gould d@ngould.dev, Bitcoin Protocol Discussion +> > bitcoin-dev@lists.linuxfoundation.org +> > Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin +> > Message-ID: +> > qLcrxFA7z6NkweC9HhZS7g9dcchQfVpjClR-nrMvjYmBobfYzbRrF37QztsuAVdM6HSZJ8U= +Hl27QKYAWq0zYQMmYnBmg0YE-7HO9S6A1Rxs=3D@protonmail.com +> >=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 b= +e much (in usual circumstances, there are tons of other transactions), it's= +, as usual with metadata, the intersection of more than one thing that coul= +d 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 relay= +s have metadata - most obviously, they can time correlate messages, with bi= +tcoin network events, so at the least they could tie transactions to client= +s. If both parties use anonymised network connections then this is ameliora= +ted (though not removed) as a vector, but then we'd need to be clear that w= +e 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? +> > >=20 +> > > Cheers, +> > > AdamISZ/waxwing +> > >=20 +> > > Sent with Proton Mail secure email. +> > >=20 +> > > ------- Original Message ------- +> > > On Wednesday, August 9th, 2023 at 11:32, Dan Gould via bitcoin-dev bi= +tcoin-dev@lists.linuxfoundation.org wrote: +> > >=20 +> > > > Hi all, +> > > >=20 +> > > > The Serverless Payjoin idea has come a long way toward formal speci= +fication of a Payjoin version 2. In the spirit of BIP 2, I?m 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. +> > > >=20 +> > > > I?ve 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. +> > > >=20 +> > > > The specifics have changed significantly compared to the first mail= +ing list post to reflect feedback. Looking forward to hear your thoughts. +> > > >=20 +> > > > Dan +> > > >=20 +> > > > <pre> +> > > >=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 +> > > > </pre> +> > > >=20 +> > > > =3D=3DAbstract=3D=3D +> > > >=20 +> > > > This document proposes a backwards-compatible second version of the= + payjoin protocol described in [[bip-0078.mediawiki|BIP 78]], allowing comp= +lete payjoin receiver functionality including payment output substitution w= +ithout requiring them to host a secure public endpoint. This requirement is= + replaced with an untrusted third-party relay and streaming clients which c= +ommunicate using an asynchronous protocol and authenticated encrypted paylo= +ads. +> > > >=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 pa= +per, that transactions with multiple inputs "necessarily reveal that their = +inputs were owned by the same owner." Breaking that common-input ownership = +assumption and others requires input from multiple owners. Cooperative tran= +saction construction also increases transaction throughput by providing new= + opportunity for payment batching and transaction cut-through. +> > > >=20 +> > > > Version 1 coordinates payjoins over a public server endpoint secure= +d by either TLS or Tor onion hidden service hosted by the receiver. Version= + 1 is synchronous, so both sender and reciever must be online simultaneousl= +y to payjoin. Both requirements present significant barriers for all but so= +phisticated server operators or those wallets with complex Tor integration.= + These barriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-d= +ev/2021-January/018358.html|regarded]] as limits to payjoin adoption. +> > > >=20 +> > > > The primary goal of this proposal is to provide a practical coordin= +ation mechanism to be adopted in a vast majority of wallet environments. Th= +is is realized as a simple protocol built on bitcoin URI requests, web stan= +dards, 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 messag= +ing for WebTransport streaming of asynchronus interactions, and leveraging = +PSBT version 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" respons= +ible for generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.= +mediawiki|BIP 21]] request URIs. Because BIP 78 messages are neither authen= +ticated nor encrypted a malicious unsecured payjoin server is able to modif= +y the Payjoin PSBT in flight, thus requiring [[payment output substitition]= +] to be disabled. Output substitition is useful for a number of block space= + optimizations, including payment batching and transaction cut-through. Thi= +s proposal introduces authentication and encryption to secure output substi= +tion 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 spe= +cifies one to be backwards compatible with version 1 senders. Receivers res= +ponding to version 1 senders must disable output substitution their payload= +s 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 Fallback PSBT timeout parameter is introduced which may also help coord= +inate the synchronous version 1 protocol. +> > > >=20 +> > > > =3D=3D=3DRelation to Stowaway=3D=3D=3D +> > > >=20 +> > > > [[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoot= +s/STOWAWAY.md|Stowaway]] is a payjoin coordination mechanism which depends = +on Tor, a third-party relay, and the [[https://samouraiwallet.com/paynym|Pa= +yNym]] [[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki|BIP= + 47]] Payment codes directory for subdirectory identification and encryptio= +n. The payjoin version 2 protocol uses one-time symmetric keys for relay su= +bdirectory identification, authentication, and encryption instead of BIP 47= + public keys derived from the wallet. Payjoin version 2 also supports async= +hronous messaging, in contrast to online Stowaway's synchronous HTTP-based = +messaging. Offline stowaway may depends on manual message passing rather th= +an an asynchronous network protocol. Successful Stowaway execution results = +in 2-output transactions, while BIP 79, 78, and this work may produce batch= +ed transactions 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 wi= +th a relay server to receive payjoin. Relays may optionally require an auth= +orization credential before allocating resources in order to prevent DoS at= +tacks. Sender and receiver payloads are buffered at the relay to support as= +ynchronous interaction. Symmetric authenticated encryption (ChaCha20-Poly13= +05 AEAD) prevents the relay from snooping on message contents or forging me= +ssages. Aside from a pre-shared secret and relayed asynchronus networking, = +the version 2 messaging takes much the same form as the existing BIP 78 spe= +cification. +> > > >=20 +> > > > =3D=3D=3DBasic scheme=3D=3D=3D +> > > >=20 +> > > > The recipient first generates a 256-bit key <code>psk</code>. This = +pre-shared key will be the basis of end-to-end authenticated encryption and= + identification 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 messag= +es. The first message must include the first 4 bytes of the Sha256 hash of = +their <code>psk</code> to be enrolled as a subdirectory identifier. The nex= +t message streamed from the relay to sender includes the enrolled subdirect= +ory payjoin endpoint. After enrollment, they await a payjoin request on a s= +ession identified by the subdirectory. Out of band, the receiver shares a [= +[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] pa= +yjoin uri including the relay endpoint in the <code>pj=3D</code> query para= +meter and the pre-shared key in a new <code>psk=3D</code> query parameter. +> > > >=20 +> > > > The sender constructs an encrypted and authenticated payload contai= +ning a PSBT and optional parameters similar to BIP 78. The resulting cipher= +text ensures message secrecy and integrity when streamed to the recipient b= +y the relay-hosted subdirectory <code>pj=3D</code> endpoint. +> > > >=20 +> > > > The sender's request is relayed to the receiver over a streaming se= +ssion at the subdirectory identified by the hash of <code>psk</code>. Messa= +ges are secured by symmetric cipher rather than TLS or Onion routing sessio= +n key. Sender and receiver may experience network interruption and proceed = +with the protocol since their request and response are buffered at the Payj= +oin relay subdirectory. +> > > >=20 +> > > > =3D=3D=3DPayjoin version 2 messaging=3D=3D=3D +> > > >=20 +> > > > Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/mast= +er/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 <code>H(psk)</code> and = +optional authentication credential according to [[#receiver-relay-enrollmen= +t|receiver relay enrollment]] protocol. It may go offline and replay enroll= +ment to come back online. +> > > >=20 +> > > > * Out of band, the receiver of the payment, shares a bitcoin URI wi= +th the sender including a <code>pj=3D</code> query parameter describing the= + relay subdirectory endpoint and <code>psk=3D</code> parameter with base64 = +encoded 256-bit secret key. To support version 1 senders the relay acts as = +an unsecured payjoin server so <code>pjos=3D0</code> must be specified in t= +he URI. Version 2 senders may safely allow output substitution regardless. +> > > >=20 +> > > > * The sender creates a valid PSBT according to [[https://github.com= +/bitcoin/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the re= +ceiver checklist]] formatted as PSBTv2. We call this the <code>Fallback PSB= +T</code>. This Fallback PSBT and optional sender parameters are encrypted a= +nd authenticated with the <code>psk</code> using ChaCha20Poly1305 and strea= +med to the relay subdirectory endpoint. +> > > >=20 +> > > > * The sender awaits a response from the relay stream containing an = +encrypted <code>Payjoin PSBT</code>. It can replay the <code>Fallback PSBT<= +/code> 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 update= +s from the relay. The receiver decrypts aund authenticates the payload then= + checks it according to [[https://github.com/bitcoin/bips/blob/master/bip-0= +078#receivers-original-psbt-checklist|the receiver checklist]]. It updates = +it to include new signed inputs and outputs invalidating sender signatures,= + and may adjust the fee. We call this the <code>Payjoin PSBT</code>. +> > > >=20 +> > > > * It responds with the <code>Payjoin PSBT</code> encrypted then aut= +henticated under <code>psk</code> using ChaCha20Poly1305. +> > > >=20 +> > > > * The relay awaits a connection from the sender if it goes offline.= + Upon connection, it relays the encrypted <code>Payjoin PSBT</code> to the = +sender. +> > > >=20 +> > > > * The sender validates the <code>Payjoin PSBT</code> according to [= +[#senders-payjoin-psbt-checklist|the sender checklist]], signs its inputs a= +nd broadcasts the transaction to the Bitcoin network. +> > > >=20 +> > > > The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as b= +ytes. +> > > >=20 +> > > > The Fallback PSBT MUST: +> > > >=20 +> > > > * Include complete UTXO data. +> > > > * Be signed. +> > > > * Exclude unnecessary fields such as global xpubs or keypath inform= +ation. <!-- I believe PSBTv2 obviates this requirement --> +> > > >=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 bat= +ching 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 = +Fallback 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= + additional 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 t= +he [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receive= +rs-original-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= +://github.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-ch= +ecklist|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 exclude= +d from the PSBT which has caused many headaches since it required the sende= +r to add them back to the Payjoin proposal PSBT. Version 2 has no such requ= +irement. +> > > >=20 +> > > > =3D=3D=3DRelay interactions=3D=3D=3D +> > > >=20 +> > > > The Payjoin Relay provides a rendezvous point for sender and receiv= +er to meet. It stores Payjoin payloads to support asynchronous communicatio= +n. It is available on the open internet over HTTPS to accept both WebTransp= +ort for Payjoin version 2, accepting encrypted payloads, and optionally HTT= +P/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. Sessi= +ons may begin by having a receiver send the first 4 bytes of the Sha256 has= +h of their <code>psk</code> to the relay. The receiver returns the subdirec= +tory endpoint url. Enrollment may be replayed in case the receiver goes off= +line. +> > > >=20 +> > > > Optionally, before returning the uri the receiver may request an au= +thentication token by presenting a message containing only the word <code>A= +uthenticate: <description></code> after which the receiver is required to s= +ubmit an <code>Authenticate: <token></code> including the token from the Re= +lay 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 aut= +hentication tokens for users of its app, or may require some proof of work = +out of band. Tokens should be anonymous credentials from the relay describi= +ng the 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 fro= +m ChaCha20Poly1305 under <code>psk</code>. +> > > >=20 +> > > > =3D=3D=3DSender interactions=3D=3D=3D +> > > >=20 +> > > > The sender starts a WebTransport session with the relay at the Payj= +oin endpoint URI provided by the receiver. It sends the following payload a= +nd awaits 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 b= +eing encrypted as follows. +> > > >=20 +> > > > <pre> +> > > >=20 +> > > > { +> > > > "psbt": "<fallback_psbt_data_base64>", +> > > >=20 +> > > > "params": { +> > > > "param1": "<value1>", +> > > >=20 +> > > > "param2": "<value1>", +> > > >=20 +> > > > ... +> > > > } +> > > > } +> > > > </pre> +> > > >=20 +> > > > The payload must be encrypted using ChaCha20Poly1305 by the sender = +using the <code>psk</code>. +> > > >=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 ver= +sion 1 is unaware of encryption when using an unsecured payjoin server. The= + Relay should convert the PSBT to PSBTv2 and construct the JSON payload fro= +m the HTTP request body and optional query parameters. Upon receiving an un= +encrypted PSBTv2 response from a receiver, it should convert it to PSBTv0 f= +or compatibility with BIP 78. +> > > >=20 +> > > > =3D=3D=3DAsynchronous relay buffers=3D=3D=3D +> > > >=20 +> > > > Each receiver subdirectory on the relay server has a buffer for req= +uests and one for responses. Each buffer updates listeners through awaitabl= +e events so that updates are immediately apparent to relevant client sessio= +ns. +> > > >=20 +> > > > =3D=3D=3DBIP 21 receiver parameters=3D=3D=3D +> > > >=20 +> > > > A major benefit of BIP 78 payjoin over other coordination mechanism= +s is its compatibility with the universal BIP 21 bitcoin URI standard. +> > > >=20 +> > > > This proposal defines the following new [[https://github.com/bitcoi= +n/bips/blob/master/bip-0021.mediawiki|BIP 21 URI]] parameters: +> > > >=20 +> > > > * <code>psk</code>: the pre-shared symmetric key for encryption and= + authentication with ChaCha20-Poly1305 +> > > >=20 +> > > > * <code>exp</code>: represents a request expiration after which the= + receiver 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 +> > > > * <code>v</code>: represents the version number of the payjoin prot= +ocol that the sender is using. This version is <code>2</code>. +> > > >=20 +> > > > BIP 78's optional query parameters are also valid as version 2 para= +meters. +> > > >=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 reques= +t PSBTs in the case of an offline counterparty. Doing so exposes a na?ve, s= +urveillance-vulnerable transaction which payjoin intends to avoid. +> > > >=20 +> > > > The existing BIP 78 protocol has to be synchronous only for automat= +ed endpoints which may be vulnerable to probing attacks. It can cover this = +tradeoff by demanding a fallback transaction that would not preserve privac= +y the same way as a payjoin. BIP 21 URI can communicate a request expiratio= +n to alleviate both of these problems. Receivers may specify a deadline aft= +er which they will broadcast this fallback with a new expiration parameter = +<code>exp=3D</code>. <!-- I also like to for timeout, but it's hard to coor= +dinate in an asynchronous way --> +> > > >=20 +> > > > =3D=3D=3DWebTransport=3D=3D=3D +> > > >=20 +> > > > Many transport protocols are good candidates for Serverless Payjoin= + functionality, but WebTransport stands out in its ability to stream and ta= +ke advantage of QUIC's performance in mobile environments. In developing th= +is BIP, serverless payjoin proofs of concept using TURN, HTTP/1.1 long poll= +ing, WebSockets, Magic Wormhole, and Nostr have been made. Streaming allows= + the relay to have more granular and asynchronous understanding of the stat= +e of the peers, and this protcol is designed specifically to address the sh= +ortcomings of an HTTP protocol's requirement to receive from a reliable, al= +ways-online connection. +> > > >=20 +> > > > While WebTransport and HTTP/3 it is built on are relatively new, wi= +despread 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 may prove advantageous for later payjoin protocols between more than = +two participants contributing inputs, such as those used to fund a lightnin= +g node with channels from multiple sources in one transaction, or those wit= +h threat models more similar to ZeroLink CoinJoin. +> > > >=20 +> > > > While Nostr is fascinating from the perspective of censorship resis= +tance, the backwards compatibility with Payjoin v1 would mean only custom N= +ostr Payjoin relays exposing an https endpoint would be suitable. Nostr tra= +nsport is also limited by the performance of WebSockets, being an abstracti= +on on top of that protocol. If Nostr authentication were used instead of a = +symmetric <code>psk</code> then those keys would also need to be communicat= +ed out of band and complicate the protocol. There is nothing stopping a new= + version of this protocol or a NIP making Payjoin version 2 possible over N= +ostr 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-= +webtransport/|a working draft for full P2P WebTransport]] without any relay= +, which 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.wik= +ipedia.org/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 a= +nd has high performance. ChaCha20Poly1305 AEAD seems to be making its way i= +nto bitcoin by way of [[https://github.com/bitcoin/bips/blob/master/bip-032= +4.mediawiki|BIP 324]] as well. The protocol has widespread support in brows= +ers, OpenSSL and libsodium. AES-GCM is more widespread but is both older, s= +lower, and not a dependency in bitcoin software. +> > > >=20 +> > > > secp256k1 asymmetric cryptography could be used, but symmetric encr= +yption allows for many fewer messages to be sent, a single ephemeral key, a= +nd seems suitable given the one time use of BIP 21 URIs for Payjoin. Payjoi= +n already requires base64 encoding for PSBTs, so we have it available to en= +code the 256-bit <code>psk</code> 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 designe= +d to have inputs and outputs be mutated. Payjoin mutates the PSBT, so BIP 7= +8 uses a hack where a new PSBT is created by the receiver instead of mutati= +ng it. This can cause some strange behaviors from signers who don't know wh= +ere to look to find the scripts that they are accountable for. PSBT version= + 2 makes mutating a PSBT's inputs and outputs trivial. It also eliminates t= +he transaction finalization step. Receivers who do not understand PSBT vers= +ion 1 may choose to reject Payjoin version 1 requests and only support PSBT= + version 2. +> > > >=20 +> > > > =3D=3D=3DAttack vectors=3D=3D=3D +> > > >=20 +> > > > Since relays store arbitrary encrypted payloads to the tragedy of t= +he commons and denial of service attacks. Relay operators may impose an aut= +hentication requirement before they provide relay service to receivers to m= +itigate such attacks. +> > > >=20 +> > > > Since <code>psk</code> is a symmetric key, the first message contai= +ning 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. +> > > >=20 +> > > > Since the Fallback PSBT is valid, even where <code>exp=3D</code> is= + specified, the receiver may broadcast it and lose out on ambiguous privacy= + protection from payjoin at any time. Though unfortunate, this is the typic= +al bitcoin 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 avail= +able via Tor hidden service or Oblivious HTTP in addition to IP / DNS to al= +low either of the peers to protect their IP from the relay with without req= +uiring both peers to use additional network security dependencies. +> > > >=20 +> > > > =3D=3DBackwards compatibility=3D=3D +> > > >=20 +> > > > The receivers advertise payjoin capabilities through [[https://gith= +ub.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]]. +> > > >=20 +> > > > Senders not supporting payjoin will just ignore the <code>pj=3D</co= +de> parameter and proceed to typical address-based transaction flows. <code= +>req-pj=3D</code> may be used to compel payjoin. +> > > >=20 +> > > > Receivers may choose to support version 1 payloads. Version 2 payjo= +in URIs should enable <code>pjos=3D0</code> so that these v1 senders disabl= +e output substitution since the v1 messages are neither encrypted nor authe= +nticated, 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 constructing an unencrypted Version 2 payload from optional query para= +meters, and PSBT in the body. +> > > >=20 +> > > > The BIP 78 error messages are already JSON formatted, so it made se= +nse 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 fou= +nd at https://github.com/payjoin/rust-payjoin/pull/78. It implements an asy= +nchronous payment flow using WebSockets using PSBTv1 without encryption. An= +other reference can be found at https://github.com/payjoin/rust-payjoin/pul= +l/21 which uses HTTP long polling for transport and Noise NNpsk0 for crypto= +. Recently, I've come to realize the rationale for WebTransport, PSBTv2, an= +d ChaCha20-Poly1305 AEAD substitutions and am working on an implementation = +including this exact specification, but wanted to get early feedback on thi= +s design in the spirit of BIP 2. +> > > >=20 +> > > > =3D=3DAcknowledgements=3D=3D +> > > >=20 +> > > > Thank you to OpenSats for funding this pursuit, to Human Rights Fou= +ndation for putting a bounty on it and funding invaluable BOB Space space s= +upport, who I owe a thank you to as well. Thank you to Ethan Heilman, Nicol= +as Dorier, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, = +Mike Schmidt, Murch, D?vid Moln?r, Lucas Ontiviero, and uncountable twitter= + plebs for feedback that has turned this idea from concept into draft, to M= +ike 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 draft= +ing process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for hac= +king 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 +> >=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 +> > End of bitcoin-dev Digest, Vol 99, Issue 25 +> > ******************************************* +>=20 +>=20 +>=20 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + |