summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAdamISZ <AdamISZ@protonmail.com>2023-08-10 15:46:18 +0000
committerbitcoindev <bitcoindev@gnusha.org>2023-08-10 15:46:34 +0000
commit54a7a55778ffb5978bbe060a82dcbeb91e92ca75 (patch)
tree106224b4913fb9ca8a2728e9abe4c1f40bc6a520
parentcb5db05186e2d078e6e6c4aede3560ed5e91a14a (diff)
downloadpi-bitcoindev-54a7a55778ffb5978bbe060a82dcbeb91e92ca75.tar.gz
pi-bitcoindev-54a7a55778ffb5978bbe060a82dcbeb91e92ca75.zip
Re: [bitcoin-dev] BIP for Serverless Payjoin
-rw-r--r--f9/31ebc80d2ea853007b916fc57642349b03fd13630
1 files changed, 630 insertions, 0 deletions
diff --git a/f9/31ebc80d2ea853007b916fc57642349b03fd13 b/f9/31ebc80d2ea853007b916fc57642349b03fd13
new file mode 100644
index 000000000..36cfb301e
--- /dev/null
+++ b/f9/31ebc80d2ea853007b916fc57642349b03fd13
@@ -0,0 +1,630 @@
+Return-Path: <AdamISZ@protonmail.com>
+Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id A0B10C0032
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 10 Aug 2023 15:46:34 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by smtp1.osuosl.org (Postfix) with ESMTP id 7B4CB83F9D
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 10 Aug 2023 15:46:34 +0000 (UTC)
+DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7B4CB83F9D
+Authentication-Results: smtp1.osuosl.org;
+ dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
+ header.a=rsa-sha256 header.s=protonmail3 header.b=TVoH4eXy
+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 smtp1.osuosl.org ([127.0.0.1])
+ by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id WsZ5xfkWLiNH
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 10 Aug 2023 15:46:32 +0000 (UTC)
+Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
+ [185.70.40.134])
+ by smtp1.osuosl.org (Postfix) with ESMTPS id 5A80683F8A
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 10 Aug 2023 15:46:32 +0000 (UTC)
+DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5A80683F8A
+Date: Thu, 10 Aug 2023 15:46:18 +0000
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
+ s=protonmail3; t=1691682388; x=1691941588;
+ bh=UiFBF72nYB1hns8afdzTTSjmi0V2LRmoJfqAKK3rWak=;
+ 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=TVoH4eXyx4yH11VUKLclAc8ekxSzJ5nbs+ozqwT71yh1yb+SP8g6Ml7i9o5mKMVID
+ Pz7Oteqvf7dXnYBa9EUzHbgchXJcGO+60cckjlcUjBrZVTBxMHMG0uZN4gfSmj+CRr
+ qf9UFV+ZAZlB9ZJ5VsUY3F6bVIKT/5glabiraFV8t+b/GmxlhUIjYcggspMJ28zDkN
+ A7j5nTS5aU4rmWjY3/bk1aXB2PXnX5dnJI1UnygUVEPCxnFndT65afPOT4CUGETKCY
+ IF4MMLQwK8a5l1yXoRRiZT0t0XZN6/4GHZu0b9VzsTF4B3CRrdhQCjdmN/VMyw3QPD
+ OKDsyzcq/Xx7g==
+To: Dan Gould <d@ngould.dev>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+From: AdamISZ <AdamISZ@protonmail.com>
+Message-ID: <qLcrxFA7z6NkweC9HhZS7g9dcchQfVpjClR-nrMvjYmBobfYzbRrF37QztsuAVdM6HSZJ8UHl27QKYAWq0zYQMmYnBmg0YE-7HO9S6A1Rxs=@protonmail.com>
+In-Reply-To: <qUoIvwrIl8ltj3TkQ7y1ExhjUan6VEpGl7c7TlHNfF1pT-eZWd_mwuNYH13YPRyvMj9OSApLmW-hwrdaHCEapEXr503SlXSywcAGceXcbow=@protonmail.com>
+References: <7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev>
+ <qUoIvwrIl8ltj3TkQ7y1ExhjUan6VEpGl7c7TlHNfF1pT-eZWd_mwuNYH13YPRyvMj9OSApLmW-hwrdaHCEapEXr503SlXSywcAGceXcbow=@protonmail.com>
+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:46:34 -0000
+
+Sorry for yet another message but:
+
+It just occurred to me that while timing correlation itself might not be mu=
+ch (in usual circumstances, there are tons of other transactions), it's, as=
+ usual with metadata, the intersection of more than one thing that could hu=
+rt: I know when the tx happens (say within a time window of 10 seconds), bu=
+t also I might know the *size* of the message. Perhaps consider random padd=
+ing of the Payjoin PSBT message size (iirc chacha is a stream cipher so len=
+gths are arbitrary).
+
+Cheers,
+AdamISZ/waxwing
+
+> Isn't the most obvious concern with this architecture, that the relays ha=
+ve metadata - most obviously, they can time correlate messages, with bitcoi=
+n network events, so at the least they could tie transactions to clients. I=
+f 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 re=
+quire those (e.g. Tor). Not sure if it's palatable to do this if otherwise,=
+ i.e. if we think the relays can tie network addresses to transactions? Wel=
+l, not sure, but I'd expect it to be mentioned?
+>=20
+> Cheers,
+> AdamISZ/waxwing
+>=20
+>=20
+> Sent with Proton Mail secure email.
+>=20
+>=20
+> ------- Original Message -------
+> On Wednesday, August 9th, 2023 at 11:32, Dan Gould via bitcoin-dev bitcoi=
+n-dev@lists.linuxfoundation.org wrote:
+>=20
+>=20
+>=20
+> > Hi all,
+> >=20
+> > The Serverless Payjoin idea has come a long way toward formal specifica=
+tion of a Payjoin version 2. In the spirit of BIP 2, I=E2=80=99m sharing an=
+ intermediate draft of the BIP here before opening a draft on GitHub for th=
+e BIP editors, and before this exact specification has a complete reference=
+ implementation. The draft does reference two proof of concept payjoin impl=
+ementations, one demonstrating use of symmetric cryptography, and the other=
+ asynchronous messaging and backwards compatibility.
+> >=20
+> > I=E2=80=99ve updated the Serverless Payjoin gist to reflect this draft =
+specification https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a=
+32f9 in order to preserve the edit history before opening a bips PR.
+> >=20
+> > The specifics have changed significantly compared to the first mailing =
+list post to reflect feedback. Looking forward to hear your thoughts.
+> >=20
+> > Dan
+> >=20
+> > <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 pay=
+join protocol described in [[bip-0078.mediawiki|BIP 78]], allowing complete=
+ payjoin receiver functionality including payment output substitution witho=
+ut requiring them to host a secure public endpoint. This requirement is rep=
+laced with an untrusted third-party relay and streaming clients which commu=
+nicate using an asynchronous protocol and authenticated encrypted payloads.
+> >=20
+> > =3D=3DCopyright=3D=3D
+> >=20
+> > This BIP is licensed under the 2-clause BSD license.
+> >=20
+> > =3D=3DMotivation=3D=3D
+> >=20
+> > Payjoin solves the sole privacy problem left open in the bitcoin paper,=
+ that transactions with multiple inputs "necessarily reveal that their inpu=
+ts were owned by the same owner." Breaking that common-input ownership assu=
+mption and others requires input from multiple owners. Cooperative transact=
+ion construction also increases transaction throughput by providing new opp=
+ortunity for payment batching and transaction cut-through.
+> >=20
+> > Version 1 coordinates payjoins over a public server endpoint secured by=
+ either TLS or Tor onion hidden service hosted by the receiver. Version 1 i=
+s synchronous, so both sender and reciever must be online simultaneously to=
+ payjoin. Both requirements present significant barriers for all but sophis=
+ticated server operators or those wallets with complex Tor integration. The=
+se barriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
+021-January/018358.html|regarded]] as limits to payjoin adoption.
+> >=20
+> > The primary goal of this proposal is to provide a practical coordinatio=
+n mechanism to be adopted in a vast majority of wallet environments. This i=
+s realized as a simple protocol built on bitcoin URI requests, web standard=
+s, common crypto, and minimal dependencies.
+> >=20
+> > =3D=3D=3DRelation to BIP 78 (Payjoin version 1)=3D=3D=3D
+> >=20
+> > The message payloads in this version parrallel those used in BIP 78 whi=
+le being encapsulated in authenticated encryption, forgoing HTTP messaging =
+for WebTransport streaming of asynchronus interactions, and leveraging PSBT=
+ version 2.
+> >=20
+> > The BIP 78 standard allows for an [[https://github.com/bitcoin/bips/blo=
+b/master/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin serv=
+er|]] to operate separately from the so-called "payment server" responsible=
+ for generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.medi=
+awiki|BIP 21]] request URIs. Because BIP 78 messages are neither authentica=
+ted nor encrypted a malicious unsecured payjoin server is able to modify th=
+e Payjoin PSBT in flight, thus requiring [[payment output substitition]] to=
+ be disabled. Output substitition is useful for a number of block space opt=
+imizations, including payment batching and transaction cut-through. This pr=
+oposal introduces authentication and encryption to secure output substition=
+ while using a relay without compromising sender or receiver privacy.
+> >=20
+> > Although unsecured payjoin server separation is mentioned in BIP 78, no=
+ known specification or implementation of one exists. This document specifi=
+es one to be backwards compatible with version 1 senders. Receivers respond=
+ing to version 1 senders must disable output substitution their payloads ar=
+e plaintext so they may payjoin without the risk of the relay stealing fund=
+s.
+> >=20
+> > The protocols in this document reuse BIP 78's BIP 21 URI parameters. A =
+Fallback PSBT timeout parameter is introduced which may also help coordinat=
+e the synchronous version 1 protocol.
+> >=20
+> > =3D=3D=3DRelation to Stowaway=3D=3D=3D
+> >=20
+> > [[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoots/ST=
+OWAWAY.md|Stowaway]] is a payjoin coordination mechanism which depends on T=
+or, a third-party relay, and the [[https://samouraiwallet.com/paynym|PayNym=
+]] [[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki|BIP 47]=
+] Payment codes directory for subdirectory identification and encryption. T=
+he payjoin version 2 protocol uses one-time symmetric keys for relay subdir=
+ectory identification, authentication, and encryption instead of BIP 47 pub=
+lic keys derived from the wallet. Payjoin version 2 also supports asynchron=
+ous messaging, in contrast to online Stowaway's synchronous HTTP-based mess=
+aging. Offline stowaway may depends on manual message passing rather than a=
+n asynchronous network protocol. Successful Stowaway execution results in 2=
+-output transactions, while BIP 79, 78, and this work may produce batched t=
+ransactions with many outputs.
+> >=20
+> > =3D=3DSpecification=3D=3D
+> >=20
+> > =3D=3D=3DOverview=3D=3D=3D
+> >=20
+> > Payjoin requests are made using familiar BIP 21 URIs. Instead of a publ=
+ic HTTP endpoint, this scheme allows a WebTransport client to enroll with a=
+ relay server to receive payjoin. Relays may optionally require an authoriz=
+ation credential before allocating resources in order to prevent DoS attack=
+s. Sender and receiver payloads are buffered at the relay to support asynch=
+ronous interaction. Symmetric authenticated encryption (ChaCha20-Poly1305 A=
+EAD) prevents the relay from snooping on message contents or forging messag=
+es. Aside from a pre-shared secret and relayed asynchronus networking, the =
+version 2 messaging takes much the same form as the existing BIP 78 specifi=
+cation.
+> >=20
+> > =3D=3D=3DBasic scheme=3D=3D=3D
+> >=20
+> > The recipient first generates a 256-bit key <code>psk</code>. This pre-=
+shared key will be the basis of end-to-end authenticated encryption and ide=
+ntification of a particular payjoin over the relay.
+> >=20
+> > Rather than hosting a public server, they start a streaming session to =
+receive messages and allocate a subdirectory from which to relay messages. =
+The first message must include the first 4 bytes of the Sha256 hash of thei=
+r <code>psk</code> to be enrolled as a subdirectory identifier. The next me=
+ssage streamed from the relay to sender includes the enrolled subdirectory =
+payjoin endpoint. After enrollment, they await a payjoin request on a sessi=
+on identified by the subdirectory. Out of band, the receiver shares a [[htt=
+ps://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] payjoi=
+n uri including the relay endpoint in the <code>pj=3D</code> query paramete=
+r and the pre-shared key in a new <code>psk=3D</code> query parameter.
+> >=20
+> > The sender constructs an encrypted and authenticated payload containing=
+ a PSBT and optional parameters similar to BIP 78. The resulting ciphertext=
+ ensures message secrecy and integrity when streamed to the recipient by th=
+e relay-hosted subdirectory <code>pj=3D</code> endpoint.
+> >=20
+> > The sender's request is relayed to the receiver over a streaming sessio=
+n at the subdirectory identified by the hash of <code>psk</code>. Messages =
+are secured by symmetric cipher rather than TLS or Onion routing session ke=
+y. Sender and receiver may experience network interruption and proceed with=
+ the protocol since their request and response are buffered at the Payjoin =
+relay subdirectory.
+> >=20
+> > =3D=3D=3DPayjoin version 2 messaging=3D=3D=3D
+> >=20
+> > Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/master/b=
+ip-0370.mediawiki|BIP 370 PSBT v2]] format to fascilitate PSBT mutation.
+> >=20
+> > The payjoin version 2 protocol takes the following steps:
+> >=20
+> > * The recipient sends the first 4 bytes of <code>H(psk)</code> and opti=
+onal authentication credential according to [[#receiver-relay-enrollment|re=
+ceiver relay enrollment]] protocol. It may go offline and replay enrollment=
+ to come back online.
+> >=20
+> > * Out of band, the receiver of the payment, shares a bitcoin URI with t=
+he sender including a <code>pj=3D</code> query parameter describing the rel=
+ay subdirectory endpoint and <code>psk=3D</code> parameter with base64 enco=
+ded 256-bit secret key. To support version 1 senders the relay acts as an u=
+nsecured payjoin server so <code>pjos=3D0</code> must be specified in the U=
+RI. Version 2 senders may safely allow output substitution regardless.
+> >=20
+> > * The sender creates a valid PSBT according to [[https://github.com/bit=
+coin/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiv=
+er checklist]] formatted as PSBTv2. We call this the <code>Fallback PSBT</c=
+ode>. This Fallback PSBT and optional sender parameters are encrypted and a=
+uthenticated 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 encr=
+ypted <code>Payjoin PSBT</code>. It can replay the <code>Fallback PSBT</cod=
+e> to request a response if it goes offline.
+> >=20
+> > * The request is stored in the receiver's subdirectory buffer.
+> > * Once the receiver is online, it awaits a stream of request updates fr=
+om the relay. The receiver decrypts aund authenticates the payload then che=
+cks it according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#=
+receivers-original-psbt-checklist|the receiver checklist]]. It updates it t=
+o include new signed inputs and outputs invalidating sender signatures, and=
+ may adjust the fee. We call this the <code>Payjoin PSBT</code>.
+> >=20
+> > * It responds with the <code>Payjoin PSBT</code> encrypted then authent=
+icated under <code>psk</code> using ChaCha20Poly1305.
+> >=20
+> > * The relay awaits a connection from the sender if it goes offline. Upo=
+n connection, it relays the encrypted <code>Payjoin PSBT</code> to the send=
+er.
+> >=20
+> > * The sender validates the <code>Payjoin PSBT</code> according to [[#se=
+nders-payjoin-psbt-checklist|the sender checklist]], signs its inputs and b=
+roadcasts the transaction to the Bitcoin network.
+> >=20
+> > The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as bytes=
+.
+> >=20
+> > The Fallback PSBT MUST:
+> >=20
+> > * Include complete UTXO data.
+> > * Be signed.
+> > * Exclude unnecessary fields such as global xpubs or keypath informatio=
+n. <!-- 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 batchin=
+g purposes.
+> > * Set SIGHASH_SINGLE Transaction Modifiable Flags flags to 1
+> >=20
+> > The Payjoin PSBT MUST:
+> >=20
+> > * Include all inputs from the Fallback PSBT.
+> > * Include all outputs which do not belong to the receiver from the Fall=
+back PSBT.
+> > * Include complete UTXO data.
+> >=20
+> > The Payjoin PSBT sender MAY:
+> >=20
+> > * Add, remove or modify Fallback PSBT outputs under the control of the =
+receiver (i.e. not sender change).
+> >=20
+> > The Payjoin PSBT MUST NOT:
+> >=20
+> > * Shuffle the order of inputs or outputs; the additional outputs or add=
+itional inputs must be inserted at a random index.
+> > * Decrease the absolute fee of the original transaction.
+> >=20
+> > =3D=3D=3DReceiver's Payjoin PSBT checklist=3D=3D=3D
+> >=20
+> > Other than requiring PSBTv2 the receiver checklist is the same as the [=
+[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-o=
+riginal-psbt-checklist|the BIP 78 receiver checklist]]
+> >=20
+> > =3D=3D=3DSender's Payjoin PSBT checklist=3D=3D=3D
+> >=20
+> > The version 2 sender's checklist is largely the same as the [[https://g=
+ithub.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-checkl=
+ist|the BIP 78 checklist]] with the exception that it expects ALL utxo data=
+ to be filled in. BIP 78 required sender inputs UTXO data to be excluded fr=
+om the PSBT which has caused many headaches since it required the sender to=
+ add them back to the Payjoin proposal PSBT. Version 2 has no such requirem=
+ent.
+> >=20
+> > =3D=3D=3DRelay interactions=3D=3D=3D
+> >=20
+> > The Payjoin Relay provides a rendezvous point for sender and receiver t=
+o meet. It stores Payjoin payloads to support asynchronous communication. I=
+t is available on the open internet over HTTPS to accept both WebTransport =
+for Payjoin version 2, accepting encrypted payloads, and optionally HTTP/1.=
+1 to support backwards compatible Payjoin version 1 requests.
+> >=20
+> > =3D=3D=3DReceiver interactions=3D=3D=3D
+> >=20
+> > =3D=3D=3D=3DRelay enrollment=3D=3D=3D=3D
+> >=20
+> > Receivers must enroll to have resources allocated on a relay. Sessions =
+may begin by having a receiver send the first 4 bytes of the Sha256 hash of=
+ their <code>psk</code> to the relay. The receiver returns the subdirectory=
+ endpoint url. Enrollment may be replayed in case the receiver goes offline=
+.
+> >=20
+> > Optionally, before returning the uri the receiver may request an authen=
+tication token by presenting a message containing only the word <code>Authe=
+nticate: <description></code> after which the receiver is required to submi=
+t an <code>Authenticate: <token></code> including the token from the Relay =
+out of band. If authentication fails an error is returned.
+> >=20
+> > In the case a relay is operated by an exchange, it may give out authent=
+ication tokens for users of its app, or may require some proof of work out =
+of band. Tokens should be anonymous credentials from the relay describing t=
+he parameters of their authorization. Specific credentialing is out of the =
+scope of this proposal.
+> >=20
+> > =3D=3D=3D=3DReceiver Payjoin PSBT response=3D=3D=3D=3D
+> >=20
+> > The receiver streams the base64 Payjoin PSBT as encrypted bytes from Ch=
+aCha20Poly1305 under <code>psk</code>.
+> >=20
+> > =3D=3D=3DSender interactions=3D=3D=3D
+> >=20
+> > The sender starts a WebTransport session with the relay at the Payjoin =
+endpoint URI provided by the receiver. It sends the following payload and a=
+waits a relayed response payload from the receiver.
+> >=20
+> > =3D=3D=3D=3DVersion 2 Fallback PSBT request=3D=3D=3D=3D
+> >=20
+> > The version 2 Fallback PSBT Payload is constructed in JSON before being=
+ encrypted as follows.
+> >=20
+> > <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 usin=
+g 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 version=
+ 1 is unaware of encryption when using an unsecured payjoin server. The Rel=
+ay should convert the PSBT to PSBTv2 and construct the JSON payload from th=
+e HTTP request body and optional query parameters. Upon receiving an unencr=
+ypted PSBTv2 response from a receiver, it should convert it to PSBTv0 for c=
+ompatibility with BIP 78.
+> >=20
+> > =3D=3D=3DAsynchronous relay buffers=3D=3D=3D
+> >=20
+> > Each receiver subdirectory on the relay server has a buffer for request=
+s and one for responses. Each buffer updates listeners through awaitable ev=
+ents so that updates are immediately apparent to relevant client sessions.
+> >=20
+> > =3D=3D=3DBIP 21 receiver parameters=3D=3D=3D
+> >=20
+> > A major benefit of BIP 78 payjoin over other coordination mechanisms is=
+ its compatibility with the universal BIP 21 bitcoin URI standard.
+> >=20
+> > This proposal defines the following new [[https://github.com/bitcoin/bi=
+ps/blob/master/bip-0021.mediawiki|BIP 21 URI]] parameters:
+> >=20
+> > * <code>psk</code>: the pre-shared symmetric key for encryption and aut=
+hentication with ChaCha20-Poly1305
+> >=20
+> > * <code>exp</code>: represents a request expiration after which the rec=
+eiver reserves the right to broadcast the Fallback and ignore requests.
+> >=20
+> > BIP 78's BIP 21 payjoin parameters are also valid for version 2.
+> >=20
+> > =3D=3D=3DOptional sender parameters=3D=3D=3D
+> >=20
+> > When the payjoin sender posts the original PSBT to the receiver, it can=
+ optionally specify the following HTTP query string parameters:
+> >=20
+> > * <code>v</code>: represents the version number of the payjoin protocol=
+ that the sender is using. This version is <code>2</code>.
+> >=20
+> > BIP 78's optional query parameters are also valid as version 2 paramete=
+rs.
+> >=20
+> > =3D=3DRationale=3D=3D
+> >=20
+> > =3D=3D=3DRequest expiration & fallback=3D=3D=3D
+> >=20
+> > The relay may hold a request for an offline payjoin peer until that pee=
+r comes online. However, the BIP 78 spec recommends broadcasting request PS=
+BTs in the case of an offline counterparty. Doing so exposes a na=C3=AFve, =
+surveillance-vulnerable transaction which payjoin intends to avoid.
+> >=20
+> > The existing BIP 78 protocol has to be synchronous only for automated e=
+ndpoints which may be vulnerable to probing attacks. It can cover this trad=
+eoff by demanding a fallback transaction that would not preserve privacy th=
+e same way as a payjoin. BIP 21 URI can communicate a request expiration to=
+ alleviate both of these problems. Receivers may specify a deadline after w=
+hich they will broadcast this fallback with a new expiration parameter <cod=
+e>exp=3D</code>. <!-- I also like to for timeout, but it's hard to coordina=
+te in an asynchronous way -->
+> >=20
+> > =3D=3D=3DWebTransport=3D=3D=3D
+> >=20
+> > Many transport protocols are good candidates for Serverless Payjoin fun=
+ctionality, but WebTransport stands out in its ability to stream and take a=
+dvantage of QUIC's performance in mobile environments. In developing this B=
+IP, serverless payjoin proofs of concept using TURN, HTTP/1.1 long polling,=
+ WebSockets, Magic Wormhole, and Nostr have been made. Streaming allows the=
+ relay to have more granular and asynchronous understanding of the state of=
+ the peers, and this protcol is designed specifically to address the shortc=
+omings of an HTTP protocol's requirement to receive from a reliable, always=
+-online connection.
+> >=20
+> > While WebTransport and HTTP/3 it is built on are relatively new, widesp=
+read support across browsers assures me that it is being accepted as a stan=
+dard and even has a fallback to HTTP/2 environments. Being built on top of =
+QUIC allows it to multiplex connections from a relay to multiple peers whic=
+h may prove advantageous for later payjoin protocols between more than two =
+participants contributing inputs, such as those used to fund a lightning no=
+de with channels from multiple sources in one transaction, or those with th=
+reat models more similar to ZeroLink CoinJoin.
+> >=20
+> > While Nostr is fascinating from the perspective of censorship resistanc=
+e, the backwards compatibility with Payjoin v1 would mean only custom Nostr=
+ Payjoin relays exposing an https endpoint would be suitable. Nostr transpo=
+rt is also limited by the performance of WebSockets, being an abstraction o=
+n top of that protocol. If Nostr authentication were used instead of a symm=
+etric <code>psk</code> then those keys would also need to be communicated o=
+ut of band and complicate the protocol. There is nothing stopping a new ver=
+sion of this protocol or a NIP making Payjoin version 2 possible over Nostr=
+ should Payjoin censorship become a bottleneck in the way of adoption.
+> >=20
+> > WebTransport is already shipped in both Firefox, Chrome, h3 in Rust, Go=
+, and all popular languages. There is also [[https://w3c.github.io/p2p-webt=
+ransport/|a working draft for full P2P WebTransport]] without any relay, wh=
+ich a future payjoin protocol may make use of.
+> >=20
+> > =3D=3D=3DChaCha20Poly1305 AEAD=3D=3D=3D
+> >=20
+> > This authenticated encryption with additional data [[https://en.wikiped=
+ia.org/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 and h=
+as high performance. ChaCha20Poly1305 AEAD seems to be making its way into =
+bitcoin by way of [[https://github.com/bitcoin/bips/blob/master/bip-0324.me=
+diawiki|BIP 324]] as well. The protocol has widespread support in browsers,=
+ OpenSSL and libsodium. AES-GCM is more widespread but is both older, slowe=
+r, and not a dependency in bitcoin software.
+> >=20
+> > secp256k1 asymmetric cryptography could be used, but symmetric encrypti=
+on allows for many fewer messages to be sent, a single ephemeral key, and s=
+eems suitable given the one time use of BIP 21 URIs for Payjoin. Payjoin al=
+ready requires base64 encoding for PSBTs, so we have it available to encode=
+ the 256-bit <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 designed to=
+ have inputs and outputs be mutated. Payjoin mutates the PSBT, so BIP 78 us=
+es a hack where a new PSBT is created by the receiver instead of mutating i=
+t. This can cause some strange behaviors from signers who don't know where =
+to look to find the scripts that they are accountable for. PSBT version 2 m=
+akes mutating a PSBT's inputs and outputs trivial. It also eliminates the t=
+ransaction finalization step. Receivers who do not understand PSBT version =
+1 may choose to reject Payjoin version 1 requests and only support PSBT ver=
+sion 2.
+> >=20
+> > =3D=3D=3DAttack vectors=3D=3D=3D
+> >=20
+> > Since relays store arbitrary encrypted payloads to the tragedy of the c=
+ommons and denial of service attacks. Relay operators may impose an authent=
+ication requirement before they provide relay service to receivers to mitig=
+ate such attacks.
+> >=20
+> > Since <code>psk</code> is a symmetric key, the first message containing=
+ the sender's original PSBT does not have forward secrecy. Since relay buff=
+ers are associated with a single ephemeral relay directory, to support requ=
+est-response simplicity of version 1, this seems appropriate.
+> >=20
+> > Since the Fallback PSBT is valid, even where <code>exp=3D</code> is spe=
+cified, the receiver may broadcast it and lose out on ambiguous privacy pro=
+tection from payjoin at any time. Though unfortunate, this is the typical b=
+itcoin transaction flow today anyhow.
+> >=20
+> > =3D=3D=3DNetwork privacy=3D=3D=3D
+> >=20
+> > Unlike BIP 78 implementations, sender and receiver peers will only see =
+the IP address of the relay, not their peer's. Relays may be made available=
+ via Tor hidden service or Oblivious HTTP in addition to IP / DNS to allow =
+either of the peers to protect their IP from the relay with without requiri=
+ng both peers to use additional network security dependencies.
+> >=20
+> > =3D=3DBackwards compatibility=3D=3D
+> >=20
+> > The receivers advertise payjoin capabilities through [[https://github.c=
+om/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]].
+> >=20
+> > Senders not supporting payjoin will just ignore the <code>pj=3D</code> =
+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 payjoin U=
+RIs should enable <code>pjos=3D0</code> so that these v1 senders disable ou=
+tput substitution since the v1 messages are neither encrypted nor authentic=
+ated, putting them at risk for man-in-the-middle attacks otherwise. The rel=
+ay protocol should carry on as normal, validating based on HTTP headers and=
+ constructing an unencrypted Version 2 payload from optional query paramete=
+rs, and PSBT in the body.
+> >=20
+> > The BIP 78 error messages are already JSON formatted, so it made sense =
+to rely on the same dependency for these payloads and error messages.
+> >=20
+> > =3D=3DReference implementation=3D=3D
+> >=20
+> > An early proof of concept draft reference implementation can be found a=
+t https://github.com/payjoin/rust-payjoin/pull/78. It implements an asynchr=
+onous payment flow using WebSockets using PSBTv1 without encryption. Anothe=
+r reference can be found at https://github.com/payjoin/rust-payjoin/pull/21=
+ which uses HTTP long polling for transport and Noise NNpsk0 for crypto. Re=
+cently, I've come to realize the rationale for WebTransport, PSBTv2, and Ch=
+aCha20-Poly1305 AEAD substitutions and am working on an implementation incl=
+uding this exact specification, but wanted to get early feedback on this de=
+sign in the spirit of BIP 2.
+> >=20
+> > =3D=3DAcknowledgements=3D=3D
+> >=20
+> > Thank you to OpenSats for funding this pursuit, to Human Rights Foundat=
+ion for putting a bounty on it and funding invaluable BOB Space space suppo=
+rt, who I owe a thank you to as well. Thank you to Ethan Heilman, Nicolas D=
+orier, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, Mike=
+ Schmidt, Murch, D=C3=A1vid Moln=C3=A1r, Lucas Ontiviero, and uncountable t=
+witter 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 writi=
+ng the "All About BIPS" zine which I've referenced a number of times in the=
+ drafting process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry f=
+or hacking on the first iOS Payjoin receiver and uncovering the problem tha=
+t this solves in the first place.
+> > _______________________________________________
+> > bitcoin-dev mailing list
+> > bitcoin-dev@lists.linuxfoundation.org
+> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+