summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAdamISZ <AdamISZ@protonmail.com>2023-08-10 15:37:54 +0000
committerbitcoindev <bitcoindev@gnusha.org>2023-08-10 15:38:05 +0000
commitcb5db05186e2d078e6e6c4aede3560ed5e91a14a (patch)
tree7aa20d8d610a104c2f37782293e0e8d73ab91fc2
parent10026e409f3ea874a563efcef88f699777abe3eb (diff)
downloadpi-bitcoindev-cb5db05186e2d078e6e6c4aede3560ed5e91a14a.tar.gz
pi-bitcoindev-cb5db05186e2d078e6e6c4aede3560ed5e91a14a.zip
Re: [bitcoin-dev] BIP for Serverless Payjoin
-rw-r--r--aa/6f0b57b04a4ac42bc30aafa02bc41cf9761488654
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
+