diff options
author | AdamISZ <AdamISZ@protonmail.com> | 2023-08-10 15:37:54 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2023-08-10 15:38:05 +0000 |
commit | cb5db05186e2d078e6e6c4aede3560ed5e91a14a (patch) | |
tree | 7aa20d8d610a104c2f37782293e0e8d73ab91fc2 | |
parent | 10026e409f3ea874a563efcef88f699777abe3eb (diff) | |
download | pi-bitcoindev-cb5db05186e2d078e6e6c4aede3560ed5e91a14a.tar.gz pi-bitcoindev-cb5db05186e2d078e6e6c4aede3560ed5e91a14a.zip |
Re: [bitcoin-dev] BIP for Serverless Payjoin
-rw-r--r-- | aa/6f0b57b04a4ac42bc30aafa02bc41cf9761488 | 654 |
1 files changed, 654 insertions, 0 deletions
diff --git a/aa/6f0b57b04a4ac42bc30aafa02bc41cf9761488 b/aa/6f0b57b04a4ac42bc30aafa02bc41cf9761488 new file mode 100644 index 000000000..5e985fa8f --- /dev/null +++ b/aa/6f0b57b04a4ac42bc30aafa02bc41cf9761488 @@ -0,0 +1,654 @@ +Return-Path: <AdamISZ@protonmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id CB799C0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <d@ngould.dev>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: AdamISZ <AdamISZ@protonmail.com> +Message-ID: <qUoIvwrIl8ltj3TkQ7y1ExhjUan6VEpGl7c7TlHNfF1pT-eZWd_mwuNYH13YPRyvMj9OSApLmW-hwrdaHCEapEXr503SlXSywcAGceXcbow=@protonmail.com> +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 <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: 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 <code>pj=3D</code> query parameter describing the relay s= +ubdirectory endpoint and <code>psk=3D</code> 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 <bitcoin= +-dev@lists.linuxfoundation.org> 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 +> <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 +>=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 <code>psk</code>. 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 = +<code>psk</code> 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 <code>pj=3D</code> query parameter = +and the pre-shared key in a new <code>psk=3D</code> 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 <code>pj=3D</code> endpoint. +>=20 +>=20 +> The sender's request is relayed to the receiver over a streaming session = +at the subdirectory identified by the hash of <code>psk</code>. 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 <code>H(psk)</code> 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 <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. To support version 1 senders the relay acts as an uns= +ecured payjoin server so <code>pjos=3D0</code> 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 <code>Fallback PSBT</cod= +e>. This Fallback PSBT and optional sender parameters are encrypted and aut= +henticated with the <code>psk</code> using ChaCha20Poly1305 and streamed to= + the relay subdirectory endpoint. +>=20 +> * The sender awaits a response from the relay stream containing an encryp= +ted <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 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 <code>Payjoin PSBT</code>. +>=20 +> * It responds with the <code>Payjoin PSBT</code> encrypted then authentic= +ated 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 [[#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.= + <!-- 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 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 <code>psk</code> 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 <code>Authent= +icate: <description></code> after which the receiver is required to submit = +an <code>Authenticate: <token></code> 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 <code>psk</code>. +>=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 +> <pre> +>=20 +> { +> "psbt": "<fallback_psbt_data_base64>", +>=20 +> "params": { +> "param1": "<value1>", +>=20 +> "param2": "<value1>", +>=20 +> ... +> } +> } +> </pre> +>=20 +>=20 +> The payload must be encrypted using ChaCha20Poly1305 by the sender using = +the <code>psk</code>. +>=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 +> * <code>psk</code>: the pre-shared symmetric key for encryption and authe= +ntication with ChaCha20-Poly1305 +>=20 +> * <code>exp</code>: 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 +> * <code>v</code>: represents the version number of the payjoin protocol t= +hat the sender is using. This version is <code>2</code>. +>=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 <code>= +exp=3D</code>. <!-- I also like to for timeout, but it's hard to coordinate= + in an asynchronous way --> +>=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 <code>psk</code> 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 <code>psk</code> 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 <code>psk</code> 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 <code>exp=3D</code> 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 <code>pj=3D</code> pa= +rameter and proceed to typical address-based transaction flows. <code>req-p= +j=3D</code> may be used to compel payjoin. +>=20 +>=20 +> Receivers may choose to support version 1 payloads. Version 2 payjoin URI= +s should enable <code>pjos=3D0</code> 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 + |