path: root/1c/692c66f56e4d98939f746582871b888f5769a1

Return-Path: <d@ngould.dev>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CB754C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Aug 2023 17:33:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id A007140525
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Aug 2023 17:33:07 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A007140525
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev
 header.a=rsa-sha256 header.s=protonmail header.b=T9RkwaJq
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.065
X-Spam-Level: 
X-Spam-Status: No, score=-0.065 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LONGWORDS=2.035,
 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 9T3lkckunbPW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Aug 2023 17:33:05 +0000 (UTC)
X-Greylist: delayed 73630 seconds by postgrey-1.37 at util1.osuosl.org;
 Wed, 09 Aug 2023 17:33:05 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1860B40280
Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 1860B40280
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Aug 2023 17:33:04 +0000 (UTC)
Date: Wed, 09 Aug 2023 17:32:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ngould.dev;
 s=protonmail; t=1691602381; x=1691861581;
 bh=C2jlF1G4pRi0PHHapti1cECeRlrtPCMsLDkPGSeuDyM=;
 h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
 b=T9RkwaJq/As9iO5xiSgpM64ybfiOhqTTdJfI3WifYalMvmBCF4h81JdpsVDNb1yhq
 zcu3lxuY4v+jKhpWAgpuW7YJ/t1UO/7YgIFsw+2TZ6Yh3YZrdluf29ynmlZ/N/VOE9
 nlvTcPzCbc/tFPizYiUaNtpzV0kMVJgUt4CEhSqw=
To: bitcoin-dev@lists.linuxfoundation.org
From: Dan Gould <d@ngould.dev>
Message-ID: <7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev>
Feedback-ID: 13175031:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 09 Aug 2023 23:17:53 +0000
Subject: [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: Wed, 09 Aug 2023 17:33:07 -0000

Hi all,

The Serverless Payjoin idea has come a long way toward formal specification=
 of a Payjoin version 2. In the spirit of BIP 2, I=E2=80=99m sharing an int=
ermediate draft of the BIP here before opening a draft on GitHub for the BI=
P editors, and before this exact specification has a complete reference imp=
lementation. The draft does reference two proof of concept payjoin implemen=
tations, one demonstrating use of symmetric cryptography, and the other asy=
nchronous messaging and backwards compatibility.

I=E2=80=99ve updated the Serverless Payjoin gist to reflect this draft spec=
ification https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9=
 in order to preserve the edit history before opening a bips PR.

The specifics have changed significantly compared to the first mailing list=
 post to reflect feedback. Looking forward to hear your thoughts.

Dan

<pre>
BIP: ???
Layer: Applications
Title: Payjoin Version 2: Serverless Payjoin
Author: Dan Gould <d@ngould.dev>
Status: Draft
Replaces: 78
Type: Standards Track
Created: 2023-08-08
License: BSD-2-Clause
</pre>

=3D=3DAbstract=3D=3D

This document proposes a backwards-compatible second version of the payjoin=
 protocol described in [[bip-0078.mediawiki|BIP 78]], allowing complete pay=
join receiver functionality including payment output substitution without r=
equiring them to host a secure public endpoint. This requirement is replace=
d with an untrusted third-party relay and streaming clients which communica=
te using an asynchronous protocol and authenticated encrypted payloads.

=3D=3DCopyright=3D=3D

This BIP is licensed under the 2-clause BSD license.

=3D=3DMotivation=3D=3D

Payjoin solves the sole privacy problem left open in the bitcoin paper, tha=
t transactions with multiple inputs "necessarily reveal that their inputs w=
ere owned by the same owner." Breaking that common-input ownership assumpti=
on and others requires input from multiple owners. Cooperative transaction =
construction also increases transaction throughput by providing new opportu=
nity for payment batching and transaction cut-through.

Version 1 coordinates payjoins over a public server endpoint secured by eit=
her TLS or Tor onion hidden service hosted by the receiver. Version 1 is sy=
nchronous, so both sender and reciever must be online simultaneously to pay=
join. Both requirements present significant barriers for all but sophistica=
ted server operators or those wallets with complex Tor integration. These b=
arriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-=
January/018358.html|regarded]] as limits to payjoin adoption.

The primary goal of this proposal is to provide a practical coordination me=
chanism to be adopted in a vast majority of wallet environments. This is re=
alized as a simple protocol built on bitcoin URI requests, web standards, c=
ommon crypto, and minimal dependencies.

=3D=3D=3DRelation to BIP 78 (Payjoin version 1)=3D=3D=3D

The message payloads in this version parrallel those used in BIP 78 while b=
eing encapsulated in authenticated encryption, forgoing HTTP messaging for =
WebTransport streaming of asynchronus interactions, and leveraging PSBT ver=
sion 2.

The BIP 78 standard allows for an [[https://github.com/bitcoin/bips/blob/ma=
ster/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin server|]=
] to operate separately from the so-called "payment server" responsible for=
 generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawik=
i|BIP 21]] request URIs. Because BIP 78 messages are neither authenticated =
nor encrypted a malicious unsecured payjoin server is able to modify the Pa=
yjoin PSBT in flight, thus requiring [[payment output substitition]] to be =
disabled. Output substitition is useful for a number of block space optimiz=
ations, including payment batching and transaction cut-through. This propos=
al introduces authentication and encryption to secure output substition whi=
le using a relay without compromising sender or receiver privacy.

Although unsecured payjoin server separation is mentioned in BIP 78, no kno=
wn specification or implementation of one exists. This document specifies o=
ne to be backwards compatible with version 1 senders. Receivers responding =
to version 1 senders must disable output substitution their payloads are pl=
aintext so they may payjoin without the risk of the relay stealing funds.

The protocols in this document reuse BIP 78's BIP 21 URI parameters. A Fall=
back PSBT timeout parameter is introduced which may also help coordinate th=
e synchronous version 1 protocol.

=3D=3D=3DRelation to Stowaway=3D=3D=3D

[[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoots/STOWAW=
AY.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]] Pa=
yment codes directory for subdirectory identification and encryption. The p=
ayjoin version 2 protocol uses one-time symmetric keys for relay subdirecto=
ry identification, authentication, and encryption instead of BIP 47 public =
keys derived from the wallet. Payjoin version 2 also supports asynchronous =
messaging, in contrast to online Stowaway's synchronous HTTP-based messagin=
g. Offline stowaway may depends on manual message passing rather than an as=
ynchronous network protocol. Successful Stowaway execution results in 2-out=
put transactions, while BIP 79, 78, and this work may produce batched trans=
actions with many outputs.

=3D=3DSpecification=3D=3D

=3D=3D=3DOverview=3D=3D=3D

Payjoin requests are made using familiar BIP 21 URIs. Instead of a public H=
TTP endpoint, this scheme allows a WebTransport client to enroll with a rel=
ay server to receive payjoin. Relays may optionally require an authorizatio=
n credential before allocating resources in order to prevent DoS attacks. S=
ender and receiver payloads are buffered at the relay to support asynchrono=
us interaction. Symmetric authenticated encryption (ChaCha20-Poly1305 AEAD)=
 prevents the relay from snooping on message contents or forging messages. =
Aside from a pre-shared secret and relayed asynchronus networking, the vers=
ion 2 messaging takes much the same form as the existing BIP 78 specificati=
on.

=3D=3D=3DBasic scheme=3D=3D=3D

The recipient first generates a 256-bit key <code>psk</code>. This pre-shar=
ed key will be the basis of end-to-end authenticated encryption and identif=
ication of a particular payjoin over the relay.

Rather than hosting a public server, they start a streaming session to rece=
ive messages and allocate a subdirectory from which to relay messages. The =
first message must include the first 4 bytes of the Sha256 hash of their <c=
ode>psk</code> to be enrolled as a subdirectory identifier. The next messag=
e streamed from the relay to sender includes the enrolled subdirectory payj=
oin endpoint. After enrollment, they await a payjoin request on a session i=
dentified by the subdirectory. Out of band, the receiver shares a [[https:/=
/github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] payjoin ur=
i including the relay endpoint in the <code>pj=3D</code> query parameter an=
d the pre-shared key in a new <code>psk=3D</code> query parameter.

The sender constructs an encrypted and authenticated payload containing a P=
SBT and optional parameters similar to BIP 78. The resulting ciphertext ens=
ures message secrecy and integrity when streamed to the recipient by the re=
lay-hosted subdirectory <code>pj=3D</code> endpoint.

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 are =
secured by symmetric cipher rather than TLS or Onion routing session key. S=
ender and receiver may experience network interruption and proceed with the=
 protocol since their request and response are buffered at the Payjoin rela=
y subdirectory.

=3D=3D=3DPayjoin version 2 messaging=3D=3D=3D

Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/master/bip-0=
370.mediawiki|BIP 370 PSBT v2]] format to fascilitate PSBT mutation.

The payjoin version 2 protocol takes the following steps:

* The recipient sends the first 4 bytes of <code>H(psk)</code> and optional=
 authentication credential according to [[#receiver-relay-enrollment|receiv=
er relay enrollment]] protocol. It may go offline and replay enrollment to =
come back online.
* 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. To support version 1 senders the relay acts as an unsec=
ured payjoin server so <code>pjos=3D0</code> must be specified in the URI. =
Version 2 senders may safely allow output substitution regardless.
* The sender creates a valid PSBT according to [[https://github.com/bitcoin=
/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiver c=
hecklist]] formatted as PSBTv2. We call this the <code>Fallback PSBT</code>=
. This Fallback PSBT and optional sender parameters are encrypted and authe=
nticated with the <code>psk</code> using ChaCha20Poly1305 and streamed to t=
he relay subdirectory endpoint.
* The sender awaits a response from the relay stream containing an encrypte=
d <code>Payjoin PSBT</code>. It can replay the <code>Fallback PSBT</code> t=
o request a response if it goes offline.
* The request is stored in the receiver's subdirectory buffer.
* Once the receiver is online, it awaits a stream of request updates from t=
he relay. The receiver decrypts aund authenticates the payload then checks =
it according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#rece=
ivers-original-psbt-checklist|the receiver checklist]]. It updates it to in=
clude new signed inputs and outputs invalidating sender signatures, and may=
 adjust the fee. We call this the <code>Payjoin PSBT</code>.
* It responds with the <code>Payjoin PSBT</code> encrypted then authenticat=
ed under <code>psk</code> using ChaCha20Poly1305.
* The relay awaits a connection from the sender if it goes offline. Upon co=
nnection, it relays the encrypted <code>Payjoin PSBT</code> to the sender.
* The sender validates the <code>Payjoin PSBT</code> according to [[#sender=
s-payjoin-psbt-checklist|the sender checklist]], signs its inputs and broad=
casts the transaction to the Bitcoin network.

The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as bytes.

The Fallback PSBT MUST:

* Include complete UTXO data.
* Be signed.
* Exclude unnecessary fields such as global xpubs or keypath information. <=
!-- I believe PSBTv2 obviates this requirement -->
* Set input and output Transaction Modifiable Flags to 1
* Be broadcastable.

The Fallback PSBT MAY:

* Include outputs unrelated to the sender-receiver transfer for batching pu=
rposes.
* Set SIGHASH_SINGLE Transaction Modifiable Flags flags to 1

The Payjoin PSBT MUST:

* Include all inputs from the Fallback PSBT.
* Include all outputs which do not belong to the receiver from the Fallback=
 PSBT.
* Include complete UTXO data.

The Payjoin PSBT sender MAY:

* Add, remove or modify Fallback PSBT outputs under the control of the rece=
iver (i.e. not sender change).

The Payjoin PSBT MUST NOT:

* Shuffle the order of inputs or outputs; the additional outputs or additio=
nal inputs must be inserted at a random index.
* Decrease the absolute fee of the original transaction.

=3D=3D=3DReceiver's Payjoin PSBT checklist=3D=3D=3D

Other than requiring PSBTv2 the receiver checklist is the same as the [[htt=
ps://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-origi=
nal-psbt-checklist|the BIP 78 receiver checklist]]

=3D=3D=3DSender's Payjoin PSBT checklist=3D=3D=3D

The version 2 sender's checklist is largely the same as the [[https://githu=
b.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-checklist|=
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 from t=
he 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 requirement.

=3D=3D=3DRelay interactions=3D=3D=3D

The Payjoin Relay provides a rendezvous point for sender and receiver to me=
et. It stores Payjoin payloads to support asynchronous communication. It 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.

=3D=3D=3DReceiver interactions=3D=3D=3D

=3D=3D=3D=3DRelay enrollment=3D=3D=3D=3D

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 the=
ir <code>psk</code> to the relay. The receiver returns the subdirectory end=
point url. Enrollment may be replayed in case the receiver goes offline.

Optionally, before returning the uri the receiver may request an authentica=
tion token by presenting a message containing only the word <code>Authentic=
ate: <description></code> after which the receiver is required to submit an=
 <code>Authenticate: <token></code> including the token from the Relay out =
of band. If authentication fails an error is returned.

In the case a relay is operated by an exchange, it may give out authenticat=
ion tokens for users of its app, or may require some proof of work out of b=
and. Tokens should be anonymous credentials from the relay describing the p=
arameters of their authorization. Specific credentialing is out of the scop=
e of this proposal.

=3D=3D=3D=3DReceiver Payjoin PSBT response=3D=3D=3D=3D

The receiver streams the base64 Payjoin PSBT as encrypted bytes from ChaCha=
20Poly1305 under <code>psk</code>.

=3D=3D=3DSender interactions=3D=3D=3D

The sender starts a WebTransport session with the relay at the Payjoin endp=
oint URI provided by the receiver. It sends the following payload and await=
s a relayed response payload from the receiver.

=3D=3D=3D=3DVersion 2 Fallback PSBT request=3D=3D=3D=3D

The version 2 Fallback PSBT Payload is constructed in JSON before being enc=
rypted as follows.

<pre>
{
"psbt": "<fallback_psbt_data_base64>",
"params": {
"param1": "<value1>",
"param2": "<value1>",
...
}
}
</pre>

The payload must be encrypted using ChaCha20Poly1305 by the sender using th=
e <code>psk</code>.

=3D=3D=3D=3DVersion 1 Fallback PSBT request=3D=3D=3D=3D

The message should be the same as version 2 but unencrypted, as version 1 i=
s unaware of encryption when using an unsecured payjoin server. The Relay s=
hould convert the PSBT to PSBTv2 and construct the JSON payload from the HT=
TP request body and optional query parameters. Upon receiving an unencrypte=
d PSBTv2 response from a receiver, it should convert it to PSBTv0 for compa=
tibility with BIP 78.

=3D=3D=3DAsynchronous relay buffers=3D=3D=3D

Each receiver subdirectory on the relay server has a buffer for requests an=
d one for responses. Each buffer updates listeners through awaitable events=
 so that updates are immediately apparent to relevant client sessions.

=3D=3D=3DBIP 21 receiver parameters=3D=3D=3D

A major benefit of BIP 78 payjoin over other coordination mechanisms is its=
 compatibility with the universal BIP 21 bitcoin URI standard.

This proposal defines the following new [[https://github.com/bitcoin/bips/b=
lob/master/bip-0021.mediawiki|BIP 21 URI]] parameters:

* <code>psk</code>: the pre-shared symmetric key for encryption and authent=
ication with ChaCha20-Poly1305
* <code>exp</code>: represents a request expiration after which the receive=
r reserves the right to broadcast the Fallback and ignore requests.

BIP 78's BIP 21 payjoin parameters are also valid for version 2.

=3D=3D=3DOptional sender parameters=3D=3D=3D

When the payjoin sender posts the original PSBT to the receiver, it can opt=
ionally specify the following HTTP query string parameters:

* <code>v</code>: represents the version number of the payjoin protocol tha=
t the sender is using. This version is <code>2</code>.

BIP 78's optional query parameters are also valid as version 2 parameters.

=3D=3DRationale=3D=3D

=3D=3D=3DRequest expiration & fallback=3D=3D=3D

The relay may hold a request for an offline payjoin peer until that peer co=
mes online. However, the BIP 78 spec recommends broadcasting request PSBTs =
in the case of an offline counterparty. Doing so exposes a na=C3=AFve, surv=
eillance-vulnerable transaction which payjoin intends to avoid.

The existing BIP 78 protocol has to be synchronous only for automated endpo=
ints which may be vulnerable to probing attacks. It can cover this tradeoff=
 by demanding a fallback transaction that would not preserve privacy the sa=
me way as a payjoin. BIP 21 URI can communicate a request expiration to all=
eviate both of these problems. Receivers may specify a deadline after which=
 they will broadcast this fallback with a new expiration parameter <code>ex=
p=3D</code>. <!-- I also like to for timeout, but it's hard to coordinate i=
n an asynchronous way -->

=3D=3D=3DWebTransport=3D=3D=3D

Many transport protocols are good candidates for Serverless Payjoin functio=
nality, but WebTransport stands out in its ability to stream and take advan=
tage of QUIC's performance in mobile environments. In developing this BIP, =
serverless payjoin proofs of concept using TURN, HTTP/1.1 long polling, Web=
Sockets, Magic Wormhole, and Nostr have been made. Streaming allows the rel=
ay to have more granular and asynchronous understanding of the state of the=
 peers, and this protcol is designed specifically to address the shortcomin=
gs of an HTTP protocol's requirement to receive from a reliable, always-onl=
ine connection.

While WebTransport and HTTP/3 it is built on are relatively new, widespread=
 support across browsers assures me that it is being accepted as a standard=
 and even has a fallback to HTTP/2 environments. Being built on top of QUIC=
 allows it to multiplex connections from a relay to multiple peers which ma=
y prove advantageous for later payjoin protocols between more than two part=
icipants contributing inputs, such as those used to fund a lightning node w=
ith channels from multiple sources in one transaction, or those with threat=
 models more similar to ZeroLink CoinJoin.

While Nostr is fascinating from the perspective of censorship resistance, t=
he backwards compatibility with Payjoin v1 would mean only custom Nostr Pay=
join relays exposing an https endpoint would be suitable. Nostr transport i=
s also limited by the performance of WebSockets, being an abstraction on to=
p of that protocol. If Nostr authentication were used instead of a symmetri=
c <code>psk</code> then those keys would also need to be communicated out o=
f band and complicate the protocol. There is nothing stopping a new version=
 of this protocol or a NIP making Payjoin version 2 possible over Nostr sho=
uld Payjoin censorship become a bottleneck in the way of adoption.

WebTransport is already shipped in both Firefox, Chrome, h3 in Rust, Go, an=
d all popular languages. There is also [[https://w3c.github.io/p2p-webtrans=
port/|a working draft for full P2P WebTransport]] without any relay, which =
a future payjoin protocol may make use of.

=3D=3D=3DChaCha20Poly1305 AEAD=3D=3D=3D

This authenticated encryption with additional data [[https://en.wikipedia.o=
rg/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 and has h=
igh performance. ChaCha20Poly1305 AEAD seems to be making its way into bitc=
oin by way of [[https://github.com/bitcoin/bips/blob/master/bip-0324.mediaw=
iki|BIP 324]] as well. The protocol has widespread support in browsers, Ope=
nSSL and libsodium. AES-GCM is more widespread but is both older, slower, a=
nd not a dependency in bitcoin software.

secp256k1 asymmetric cryptography could be used, but symmetric encryption a=
llows for many fewer messages to be sent, a single ephemeral key, and seems=
 suitable given the one time use of BIP 21 URIs for Payjoin. Payjoin alread=
y requires base64 encoding for PSBTs, so we have it available to encode the=
 256-bit <code>psk</code> in the BIP 21 parameter.

=3D=3D=3DPSBT Version 2=3D=3D=3D

The PSBT version 1 protocol was replaced because it was not designed to hav=
e 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. T=
his can cause some strange behaviors from signers who don't know where to l=
ook to find the scripts that they are accountable for. PSBT version 2 makes=
 mutating a PSBT's inputs and outputs trivial. It also eliminates the trans=
action finalization step. Receivers who do not understand PSBT version 1 ma=
y choose to reject Payjoin version 1 requests and only support PSBT version=
 2.

=3D=3D=3DAttack vectors=3D=3D=3D

Since relays store arbitrary encrypted payloads to the tragedy of the commo=
ns and denial of service attacks. Relay operators may impose an authenticat=
ion requirement before they provide relay service to receivers to mitigate =
such attacks.

Since <code>psk</code> is a symmetric key, the first message containing the=
 sender's original PSBT does not have forward secrecy. Since relay buffers =
are associated with a single ephemeral relay directory, to support request-=
response simplicity of version 1, this seems appropriate.

Since the Fallback PSBT is valid, even where <code>exp=3D</code> is specifi=
ed, the receiver may broadcast it and lose out on ambiguous privacy protect=
ion from payjoin at any time. Though unfortunate, this is the typical bitco=
in transaction flow today anyhow.

=3D=3D=3DNetwork privacy=3D=3D=3D

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 eith=
er of the peers to protect their IP from the relay with without requiring b=
oth peers to use additional network security dependencies.

=3D=3DBackwards compatibility=3D=3D

The receivers advertise payjoin capabilities through [[https://github.com/b=
itcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]].

Senders not supporting payjoin will just ignore the <code>pj=3D</code> para=
meter 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 URIs =
should enable <code>pjos=3D0</code> so that these v1 senders disable output=
 substitution since the v1 messages are neither encrypted nor authenticated=
, putting them at risk for man-in-the-middle attacks otherwise. The relay p=
rotocol should carry on as normal, validating based on HTTP headers and con=
structing an unencrypted Version 2 payload from optional query parameters, =
and PSBT in the body.

The BIP 78 error messages are already JSON formatted, so it made sense to r=
ely on the same dependency for these payloads and error messages.

=3D=3DReference implementation=3D=3D

An early proof of concept draft reference implementation can be found at ht=
tps://github.com/payjoin/rust-payjoin/pull/78. It implements an asynchronou=
s payment flow using WebSockets using PSBTv1 without encryption. Another re=
ference can be found at https://github.com/payjoin/rust-payjoin/pull/21 whi=
ch uses HTTP long polling for transport and Noise NNpsk0 for crypto. Recent=
ly, I've come to realize the rationale for WebTransport, PSBTv2, and ChaCha=
20-Poly1305 AEAD substitutions and am working on an implementation includin=
g this exact specification, but wanted to get early feedback on this design=
 in the spirit of BIP 2.

=3D=3DAcknowledgements=3D=3D

Thank you to OpenSats for funding this pursuit, to Human Rights Foundation =
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 Dorie=
r, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, Mike Sch=
midt, Murch, D=C3=A1vid Moln=C3=A1r, Lucas Ontiviero, and uncountable twitt=
er 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 t=
he "All About BIPS" zine which I've referenced a number of times in the dra=
fting process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for h=
acking on the first iOS Payjoin receiver and uncovering the problem that th=
is solves in the first place.