Date: Fri, 11 Aug 2023 22:04:23 +0000
To: Dan Gould <d@ngould.dev>
From: symphonicbtc <symphonicbtc@proton.me>
Message-ID: <P1bXSK5FgAsqtckOyZmQ4U6XyKJavBuDC92FgE_R4osiQJIIEDndFRPBFJsU6vO0fhioctnDV9MKp1sYoCfSwswUbFfkglxHEvYaNMo67fI=@proton.me>
In-Reply-To: <50A19B79-46A1-4F21-AA53-74356F4B0CBA@ngould.dev>
References: <mailman.130337.1691684480.956.bitcoin-dev@lists.linuxfoundation.org>
 <50A19B79-46A1-4F21-AA53-74356F4B0CBA@ngould.dev>
Feedback-ID: 77757318:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin (AdamISZ)
Precedence: list

Hey Dan,

Very interested in such a protocol finally becoming standardized. Quick lit=
tle nit I noticed as well, are you sure base64 encoding is the best choice =
for the psk in the URI? You may find that having to urlencode the special c=
haracters in base64 it impacts readability and adds a layer of complexity i=
f a human wanted to extract the psk from the URI for some reason. I suggest=
 using something like [base64url](https://datatracker.ietf.org/doc/html/rfc=
4648#section-5) which modifies base64 slightly to be more suited to this pu=
rpose.

Symphonic

------- Original Message -------
On Friday, August 11th, 2023 at 5:03 PM, Dan Gould via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:


> Hi waxwing
>=20
> thanks for the detailed response. You've identified a number of flaws bot=
h in the protocol and the document that can be fixed. I sincerely appreciat=
e it. If more comes to mind, fire away.
>=20
> > I wanted to immediately "nit" a point I saw as I was reading:
> >=20
> > > Because BIP 78 messages are neither authenticated nor encrypted a mal=
icious unsecured payjoin server is able to modify the Payjoin PSBT in fligh=
t,
> >=20
> > Taken as is - i.e. out of context! - this is just wrong. The BIP explic=
itly states:
> >=20
> > "The sender must ensure that the url refers to a scheme or protocol usi=
ng authenticated encryption, for example TLS with certificate validation, o=
r a .onion link to a hidden service whose public key identifier has already=
 been communicated via a TLS connection. Senders SHOULD NOT accept a url re=
presenting an unencrypted or unauthenticated connection. "
>=20
>=20
> Nice Catch. I've fixed it in the draft.
>=20
> > Out of band, the receiver of the payment, shares a bitcoin URI with the=
 sender including a <code>pj=3D</code> query parameter describing the relay=
 subdirectory endpoint and <code>psk=3D</code> parameter with base64 encode=
d 256-bit secret key.
>=20
> > You're sending the symmetric secret key out of band; but isn't this obs=
curing the question of securely sharing the secret key? Did you consider DH=
-ing this as other protocols do? At the very least I would claim that it's =
likely that implementers might be sloppy here; at the most I would claim th=
is is just insecure full stop.
>=20
>=20
> At first I thought this would be secure because the relay itself would ne=
ed to discover the key only to uncover privacy, but because of output subst=
itution it would actually open the protocol to a loss of funds attack: If t=
he ask-containing bip21 were discovered by the relay, then the relay would =
have enough information to both find the buffer and forge a Payjoin PSBT pa=
ying itself rather than the receiver, and the sender would send it because =
output substitution is allowed. Even though I handle bip21s and addresses a=
s secret, I know many people post them in unencrypted channels and so they =
should not be assumed secure to pass secrets.
>=20
> I have certainly considered the security trade offs of using a symmetric =
key vs DH. The main reason I chose to use the symmetric psk over DH is beca=
use I thought DH would require another round of communication to establish =
receiver authentication, which is a huge inconvenience in an asynchronous s=
etting. The attack I=E2=80=99ve described can be mitigated inside the same =
message pattern by having receiver share a public key of a per-request keyp=
air Instead, approximately following the NKpsk0 pattern, the sender may pas=
s an ephemeral secret session key under which the Payjoin PSBT response wou=
ld be encrypted and authenticated so no malicious adversary with knowledge =
of the bip21 would be unable to read or forge. Stowaway uses BIP 47 codes f=
or this purpose, but I see no reason to tie buffer identity to the underlyi=
ng wallet. Using ephemeral keys also allows a single receiver to enroll mul=
tiple buffers at a relay simultaneously.
>=20
> > About attack vectors:
> >=20
> > Since relays store arbitrary encrypted payloads to the tragedy of the c=
ommons and denial of service attacks. Relay operators may impose an authent=
ication requirement before they provide relay service to receivers to mitig=
ate such attacks.
> >=20
> > Isn't the most obvious concern with this architecture, that the relays =
have metadata - most obviously, they can time correlate messages, with bitc=
oin network events, so at the least they could tie transactions to clients.=
 If both parties use anonymised network connections then this is ameliorate=
d (though not removed) as a vector, but then we'd need to be clear that we =
require those (e.g. Tor). Not sure if it's palatable to do this if otherwis=
e, i.e. if we think the relays can tie network addresses to transactions? W=
ell, not sure, but I'd expect it to be mentioned?
>=20
>=20
> The most obvious concern with this architecture is indeed that the relays=
 would have metadata that could be used for timing attacks correlating to a=
 Payjoin PSBT buffer being cleared from the relay and a potential payjoin t=
ransaction being broadcast. If a sufficient number of steganographic transa=
ctions are broadcast per quantum, then requiring a sender to broadcast only=
 after a random delay based on a poisson distribution could mitigate this p=
roblem somewhat. According to S. Ghesmati 2020 research, between 27% and 42=
% of all transactions conform to the type of unnecessary input heuristic th=
at payjoins conform to (UIH2). So it wouldn=E2=80=99t take long for multipl=
e steganographic candidates to enter the Mempool at any given time.
>=20
> I'm extremely reluctant to require Tor because it severely limits the num=
ber of environments where this proposal could be deployed. If we were to re=
quire Tor, we should then just ignore this proposal and focus on deploying =
hidden service based v1 receivers as in JoinMarket. I'm more inclined to re=
quire Oblivious HTTP but even that seems overkill when the threat would be =
for the relay to correlate steganographic transactions, which don't have a =
single clear sender/receiver interpretation, to two ip addresses.
>=20
> > It just occurred to me that while timing correlation itself might not b=
e much (in usual circumstances, there are tons of other transactions), it's=
, as usual with metadata, the intersection of more than one thing that coul=
d hurt: I know when the tx happens (say within a time window of 10 seconds)=
, but also I might know the size of the message. Perhaps consider random pa=
dding of the Payjoin PSBT message size (iirc chacha is a stream cipher so l=
engths are arbitrary).
>=20
>=20
> The biggest intersection attack is timing correlation of two linked poten=
tial payjoin transactions related to one IP address. Again, a specified del=
ay may help mitigate this concern.
>=20
> I agree that padding ought to be a requirement. 4M block size limit with =
base64 encoding overhead seems like a resonable buffer size, but PSBTs have=
 significant overhead compared to consensus transactions, so the exact size=
 of a buffer needs more attention.
>=20
> Thanks for the feedback,
> Dan
>=20
> > On Aug 10, 2023, at 12:21 PM, bitcoin-dev-request@lists.linuxfoundation=
.org bitcoin-dev-request@lists.linuxfoundation.org wrote:
> >=20
> > Send bitcoin-dev mailing list submissions to
> > bitcoin-dev@lists.linuxfoundation.org
> >=20
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > or, via email, send a message with subject or body 'help' to
> > bitcoin-dev-request@lists.linuxfoundation.org
> >=20
> > You can reach the person managing the list at
> > bitcoin-dev-owner@lists.linuxfoundation.org
> >=20
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of bitcoin-dev digest..."
> >=20
> > Today's Topics:
> >=20
> > 1. Re: BIP for Serverless Payjoin (AdamISZ)
> >=20
> > ----------------------------------------------------------------------
> >=20
> > Message: 1
> > Date: Thu, 10 Aug 2023 15:46:18 +0000
> > From: AdamISZ AdamISZ@protonmail.com
> > To: Dan Gould d@ngould.dev, Bitcoin Protocol Discussion
> > bitcoin-dev@lists.linuxfoundation.org
> > Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin
> > Message-ID:
> > qLcrxFA7z6NkweC9HhZS7g9dcchQfVpjClR-nrMvjYmBobfYzbRrF37QztsuAVdM6HSZJ8U=
Hl27QKYAWq0zYQMmYnBmg0YE-7HO9S6A1Rxs=3D@protonmail.com
> >=20
> > Content-Type: text/plain; charset=3Dutf-8
> >=20
> > Sorry for yet another message but:
> >=20
> > It just occurred to me that while timing correlation itself might not b=
e much (in usual circumstances, there are tons of other transactions), it's=
, as usual with metadata, the intersection of more than one thing that coul=
d hurt: I know when the tx happens (say within a time window of 10 seconds)=
, but also I might know the size of the message. Perhaps consider random pa=
dding of the Payjoin PSBT message size (iirc chacha is a stream cipher so l=
engths are arbitrary).
> >=20
> > Cheers,
> > AdamISZ/waxwing
> >=20
> > > Isn't the most obvious concern with this architecture, that the relay=
s have metadata - most obviously, they can time correlate messages, with bi=
tcoin network events, so at the least they could tie transactions to client=
s. If both parties use anonymised network connections then this is ameliora=
ted (though not removed) as a vector, but then we'd need to be clear that w=
e require those (e.g. Tor). Not sure if it's palatable to do this if otherw=
ise, i.e. if we think the relays can tie network addresses to transactions?=
 Well, not sure, but I'd expect it to be mentioned?
> > >=20
> > > Cheers,
> > > AdamISZ/waxwing
> > >=20
> > > Sent with Proton Mail secure email.
> > >=20
> > > ------- Original Message -------
> > > On Wednesday, August 9th, 2023 at 11:32, Dan Gould via bitcoin-dev bi=
tcoin-dev@lists.linuxfoundation.org wrote:
> > >=20
> > > > Hi all,
> > > >=20
> > > > The Serverless Payjoin idea has come a long way toward formal speci=
fication of a Payjoin version 2. In the spirit of BIP 2, I?m sharing an int=
ermediate draft of the BIP here before opening a draft on GitHub for the BI=
P editors, and before this exact specification has a complete reference imp=
lementation. The draft does reference two proof of concept payjoin implemen=
tations, one demonstrating use of symmetric cryptography, and the other asy=
nchronous messaging and backwards compatibility.
> > > >=20
> > > > I?ve updated the Serverless Payjoin gist to reflect this draft spec=
ification https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9=
 in order to preserve the edit history before opening a bips PR.
> > > >=20
> > > > The specifics have changed significantly compared to the first mail=
ing list post to reflect feedback. Looking forward to hear your thoughts.
> > > >=20
> > > > Dan
> > > >=20
> > > > <pre>
> > > >=20
> > > > BIP: ???
> > > > Layer: Applications
> > > > Title: Payjoin Version 2: Serverless Payjoin
> > > > Author: Dan Gould d@ngould.dev
> > > >=20
> > > > Status: Draft
> > > > Replaces: 78
> > > > Type: Standards Track
> > > > Created: 2023-08-08
> > > > License: BSD-2-Clause
> > > > </pre>
> > > >=20
> > > > =3D=3DAbstract=3D=3D
> > > >=20
> > > > This document proposes a backwards-compatible second version of the=
 payjoin protocol described in [[bip-0078.mediawiki|BIP 78]], allowing comp=
lete payjoin receiver functionality including payment output substitution w=
ithout requiring them to host a secure public endpoint. This requirement is=
 replaced with an untrusted third-party relay and streaming clients which c=
ommunicate using an asynchronous protocol and authenticated encrypted paylo=
ads.
> > > >=20
> > > > =3D=3DCopyright=3D=3D
> > > >=20
> > > > This BIP is licensed under the 2-clause BSD license.
> > > >=20
> > > > =3D=3DMotivation=3D=3D
> > > >=20
> > > > Payjoin solves the sole privacy problem left open in the bitcoin pa=
per, that transactions with multiple inputs "necessarily reveal that their =
inputs were owned by the same owner." Breaking that common-input ownership =
assumption and others requires input from multiple owners. Cooperative tran=
saction construction also increases transaction throughput by providing new=
 opportunity for payment batching and transaction cut-through.
> > > >=20
> > > > Version 1 coordinates payjoins over a public server endpoint secure=
d by either TLS or Tor onion hidden service hosted by the receiver. Version=
 1 is synchronous, so both sender and reciever must be online simultaneousl=
y to payjoin. Both requirements present significant barriers for all but so=
phisticated server operators or those wallets with complex Tor integration.=
 These barriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-d=
ev/2021-January/018358.html|regarded]] as limits to payjoin adoption.
> > > >=20
> > > > The primary goal of this proposal is to provide a practical coordin=
ation mechanism to be adopted in a vast majority of wallet environments. Th=
is is realized as a simple protocol built on bitcoin URI requests, web stan=
dards, common crypto, and minimal dependencies.
> > > >=20
> > > > =3D=3D=3DRelation to BIP 78 (Payjoin version 1)=3D=3D=3D
> > > >=20
> > > > The message payloads in this version parrallel those used in BIP 78=
 while being encapsulated in authenticated encryption, forgoing HTTP messag=
ing for WebTransport streaming of asynchronus interactions, and leveraging =
PSBT version 2.
> > > >=20
> > > > The BIP 78 standard allows for an [[https://github.com/bitcoin/bips=
/blob/master/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin =
server|]] to operate separately from the so-called "payment server" respons=
ible for generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.=
mediawiki|BIP 21]] request URIs. Because BIP 78 messages are neither authen=
ticated nor encrypted a malicious unsecured payjoin server is able to modif=
y the Payjoin PSBT in flight, thus requiring [[payment output substitition]=
] to be disabled. Output substitition is useful for a number of block space=
 optimizations, including payment batching and transaction cut-through. Thi=
s proposal introduces authentication and encryption to secure output substi=
tion while using a relay without compromising sender or receiver privacy.
> > > >=20
> > > > Although unsecured payjoin server separation is mentioned in BIP 78=
, no known specification or implementation of one exists. This document spe=
cifies one to be backwards compatible with version 1 senders. Receivers res=
ponding to version 1 senders must disable output substitution their payload=
s are plaintext so they may payjoin without the risk of the relay stealing =
funds.
> > > >=20
> > > > The protocols in this document reuse BIP 78's BIP 21 URI parameters=
. A Fallback PSBT timeout parameter is introduced which may also help coord=
inate the synchronous version 1 protocol.
> > > >=20
> > > > =3D=3D=3DRelation to Stowaway=3D=3D=3D
> > > >=20
> > > > [[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoot=
s/STOWAWAY.md|Stowaway]] is a payjoin coordination mechanism which depends =
on Tor, a third-party relay, and the [[https://samouraiwallet.com/paynym|Pa=
yNym]] [[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki|BIP=
 47]] Payment codes directory for subdirectory identification and encryptio=
n. The payjoin version 2 protocol uses one-time symmetric keys for relay su=
bdirectory identification, authentication, and encryption instead of BIP 47=
 public keys derived from the wallet. Payjoin version 2 also supports async=
hronous messaging, in contrast to online Stowaway's synchronous HTTP-based =
messaging. Offline stowaway may depends on manual message passing rather th=
an an asynchronous network protocol. Successful Stowaway execution results =
in 2-output transactions, while BIP 79, 78, and this work may produce batch=
ed transactions with many outputs.
> > > >=20
> > > > =3D=3DSpecification=3D=3D
> > > >=20
> > > > =3D=3D=3DOverview=3D=3D=3D
> > > >=20
> > > > Payjoin requests are made using familiar BIP 21 URIs. Instead of a =
public HTTP endpoint, this scheme allows a WebTransport client to enroll wi=
th a relay server to receive payjoin. Relays may optionally require an auth=
orization credential before allocating resources in order to prevent DoS at=
tacks. Sender and receiver payloads are buffered at the relay to support as=
ynchronous interaction. Symmetric authenticated encryption (ChaCha20-Poly13=
05 AEAD) prevents the relay from snooping on message contents or forging me=
ssages. Aside from a pre-shared secret and relayed asynchronus networking, =
the version 2 messaging takes much the same form as the existing BIP 78 spe=
cification.
> > > >=20
> > > > =3D=3D=3DBasic scheme=3D=3D=3D
> > > >=20
> > > > The recipient first generates a 256-bit key <code>psk</code>. This =
pre-shared key will be the basis of end-to-end authenticated encryption and=
 identification of a particular payjoin over the relay.
> > > >=20
> > > > Rather than hosting a public server, they start a streaming session=
 to receive messages and allocate a subdirectory from which to relay messag=
es. The first message must include the first 4 bytes of the Sha256 hash of =
their <code>psk</code> to be enrolled as a subdirectory identifier. The nex=
t message streamed from the relay to sender includes the enrolled subdirect=
ory payjoin endpoint. After enrollment, they await a payjoin request on a s=
ession identified by the subdirectory. Out of band, the receiver shares a [=
[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] pa=
yjoin uri including the relay endpoint in the <code>pj=3D</code> query para=
meter and the pre-shared key in a new <code>psk=3D</code> query parameter.
> > > >=20
> > > > The sender constructs an encrypted and authenticated payload contai=
ning a PSBT and optional parameters similar to BIP 78. The resulting cipher=
text ensures message secrecy and integrity when streamed to the recipient b=
y the relay-hosted subdirectory <code>pj=3D</code> endpoint.
> > > >=20
> > > > The sender's request is relayed to the receiver over a streaming se=
ssion at the subdirectory identified by the hash of <code>psk</code>. Messa=
ges are secured by symmetric cipher rather than TLS or Onion routing sessio=
n key. Sender and receiver may experience network interruption and proceed =
with the protocol since their request and response are buffered at the Payj=
oin relay subdirectory.
> > > >=20
> > > > =3D=3D=3DPayjoin version 2 messaging=3D=3D=3D
> > > >=20
> > > > Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/mast=
er/bip-0370.mediawiki|BIP 370 PSBT v2]] format to fascilitate PSBT mutation=
.
> > > >=20
> > > > The payjoin version 2 protocol takes the following steps:
> > > >=20
> > > > * The recipient sends the first 4 bytes of <code>H(psk)</code> and =
optional authentication credential according to [[#receiver-relay-enrollmen=
t|receiver relay enrollment]] protocol. It may go offline and replay enroll=
ment to come back online.
> > > >=20
> > > > * Out of band, the receiver of the payment, shares a bitcoin URI wi=
th the sender including a <code>pj=3D</code> query parameter describing the=
 relay subdirectory endpoint and <code>psk=3D</code> parameter with base64 =
encoded 256-bit secret key. To support version 1 senders the relay acts as =
an unsecured payjoin server so <code>pjos=3D0</code> must be specified in t=
he URI. Version 2 senders may safely allow output substitution regardless.
> > > >=20
> > > > * The sender creates a valid PSBT according to [[https://github.com=
/bitcoin/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the re=
ceiver checklist]] formatted as PSBTv2. We call this the <code>Fallback PSB=
T</code>. This Fallback PSBT and optional sender parameters are encrypted a=
nd authenticated with the <code>psk</code> using ChaCha20Poly1305 and strea=
med to the relay subdirectory endpoint.
> > > >=20
> > > > * The sender awaits a response from the relay stream containing an =
encrypted <code>Payjoin PSBT</code>. It can replay the <code>Fallback PSBT<=
/code> to request a response if it goes offline.
> > > >=20
> > > > * The request is stored in the receiver's subdirectory buffer.
> > > > * Once the receiver is online, it awaits a stream of request update=
s from the relay. The receiver decrypts aund authenticates the payload then=
 checks it according to [[https://github.com/bitcoin/bips/blob/master/bip-0=
078#receivers-original-psbt-checklist|the receiver checklist]]. It updates =
it to include new signed inputs and outputs invalidating sender signatures,=
 and may adjust the fee. We call this the <code>Payjoin PSBT</code>.
> > > >=20
> > > > * It responds with the <code>Payjoin PSBT</code> encrypted then aut=
henticated under <code>psk</code> using ChaCha20Poly1305.
> > > >=20
> > > > * The relay awaits a connection from the sender if it goes offline.=
 Upon connection, it relays the encrypted <code>Payjoin PSBT</code> to the =
sender.
> > > >=20
> > > > * The sender validates the <code>Payjoin PSBT</code> according to [=
[#senders-payjoin-psbt-checklist|the sender checklist]], signs its inputs a=
nd broadcasts the transaction to the Bitcoin network.
> > > >=20
> > > > The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as b=
ytes.
> > > >=20
> > > > The Fallback PSBT MUST:
> > > >=20
> > > > * Include complete UTXO data.
> > > > * Be signed.
> > > > * Exclude unnecessary fields such as global xpubs or keypath inform=
ation. <!-- I believe PSBTv2 obviates this requirement -->
> > > >=20
> > > > * Set input and output Transaction Modifiable Flags to 1
> > > > * Be broadcastable.
> > > >=20
> > > > The Fallback PSBT MAY:
> > > >=20
> > > > * Include outputs unrelated to the sender-receiver transfer for bat=
ching purposes.
> > > > * Set SIGHASH_SINGLE Transaction Modifiable Flags flags to 1
> > > >=20
> > > > The Payjoin PSBT MUST:
> > > >=20
> > > > * Include all inputs from the Fallback PSBT.
> > > > * Include all outputs which do not belong to the receiver from the =
Fallback PSBT.
> > > > * Include complete UTXO data.
> > > >=20
> > > > The Payjoin PSBT sender MAY:
> > > >=20
> > > > * Add, remove or modify Fallback PSBT outputs under the control of =
the receiver (i.e. not sender change).
> > > >=20
> > > > The Payjoin PSBT MUST NOT:
> > > >=20
> > > > * Shuffle the order of inputs or outputs; the additional outputs or=
 additional inputs must be inserted at a random index.
> > > > * Decrease the absolute fee of the original transaction.
> > > >=20
> > > > =3D=3D=3DReceiver's Payjoin PSBT checklist=3D=3D=3D
> > > >=20
> > > > Other than requiring PSBTv2 the receiver checklist is the same as t=
he [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receive=
rs-original-psbt-checklist|the BIP 78 receiver checklist]]
> > > >=20
> > > > =3D=3D=3DSender's Payjoin PSBT checklist=3D=3D=3D
> > > >=20
> > > > The version 2 sender's checklist is largely the same as the [[https=
://github.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-ch=
ecklist|the BIP 78 checklist]] with the exception that it expects ALL utxo =
data to be filled in. BIP 78 required sender inputs UTXO data to be exclude=
d from the PSBT which has caused many headaches since it required the sende=
r to add them back to the Payjoin proposal PSBT. Version 2 has no such requ=
irement.
> > > >=20
> > > > =3D=3D=3DRelay interactions=3D=3D=3D
> > > >=20
> > > > The Payjoin Relay provides a rendezvous point for sender and receiv=
er to meet. It stores Payjoin payloads to support asynchronous communicatio=
n. It is available on the open internet over HTTPS to accept both WebTransp=
ort for Payjoin version 2, accepting encrypted payloads, and optionally HTT=
P/1.1 to support backwards compatible Payjoin version 1 requests.
> > > >=20
> > > > =3D=3D=3DReceiver interactions=3D=3D=3D
> > > >=20
> > > > =3D=3D=3D=3DRelay enrollment=3D=3D=3D=3D
> > > >=20
> > > > Receivers must enroll to have resources allocated on a relay. Sessi=
ons may begin by having a receiver send the first 4 bytes of the Sha256 has=
h of their <code>psk</code> to the relay. The receiver returns the subdirec=
tory endpoint url. Enrollment may be replayed in case the receiver goes off=
line.
> > > >=20
> > > > Optionally, before returning the uri the receiver may request an au=
thentication token by presenting a message containing only the word <code>A=
uthenticate: <description></code> after which the receiver is required to s=
ubmit an <code>Authenticate: <token></code> including the token from the Re=
lay out of band. If authentication fails an error is returned.
> > > >=20
> > > > In the case a relay is operated by an exchange, it may give out aut=
hentication tokens for users of its app, or may require some proof of work =
out of band. Tokens should be anonymous credentials from the relay describi=
ng the parameters of their authorization. Specific credentialing is out of =
the scope of this proposal.
> > > >=20
> > > > =3D=3D=3D=3DReceiver Payjoin PSBT response=3D=3D=3D=3D
> > > >=20
> > > > The receiver streams the base64 Payjoin PSBT as encrypted bytes fro=
m ChaCha20Poly1305 under <code>psk</code>.
> > > >=20
> > > > =3D=3D=3DSender interactions=3D=3D=3D
> > > >=20
> > > > The sender starts a WebTransport session with the relay at the Payj=
oin endpoint URI provided by the receiver. It sends the following payload a=
nd awaits a relayed response payload from the receiver.
> > > >=20
> > > > =3D=3D=3D=3DVersion 2 Fallback PSBT request=3D=3D=3D=3D
> > > >=20
> > > > The version 2 Fallback PSBT Payload is constructed in JSON before b=
eing encrypted as follows.
> > > >=20
> > > > <pre>
> > > >=20
> > > > {
> > > > "psbt": "<fallback_psbt_data_base64>",
> > > >=20
> > > > "params": {
> > > > "param1": "<value1>",
> > > >=20
> > > > "param2": "<value1>",
> > > >=20
> > > > ...
> > > > }
> > > > }
> > > > </pre>
> > > >=20
> > > > The payload must be encrypted using ChaCha20Poly1305 by the sender =
using the <code>psk</code>.
> > > >=20
> > > > =3D=3D=3D=3DVersion 1 Fallback PSBT request=3D=3D=3D=3D
> > > >=20
> > > > The message should be the same as version 2 but unencrypted, as ver=
sion 1 is unaware of encryption when using an unsecured payjoin server. The=
 Relay should convert the PSBT to PSBTv2 and construct the JSON payload fro=
m the HTTP request body and optional query parameters. Upon receiving an un=
encrypted PSBTv2 response from a receiver, it should convert it to PSBTv0 f=
or compatibility with BIP 78.
> > > >=20
> > > > =3D=3D=3DAsynchronous relay buffers=3D=3D=3D
> > > >=20
> > > > Each receiver subdirectory on the relay server has a buffer for req=
uests and one for responses. Each buffer updates listeners through awaitabl=
e events so that updates are immediately apparent to relevant client sessio=
ns.
> > > >=20
> > > > =3D=3D=3DBIP 21 receiver parameters=3D=3D=3D
> > > >=20
> > > > A major benefit of BIP 78 payjoin over other coordination mechanism=
s is its compatibility with the universal BIP 21 bitcoin URI standard.
> > > >=20
> > > > This proposal defines the following new [[https://github.com/bitcoi=
n/bips/blob/master/bip-0021.mediawiki|BIP 21 URI]] parameters:
> > > >=20
> > > > * <code>psk</code>: the pre-shared symmetric key for encryption and=
 authentication with ChaCha20-Poly1305
> > > >=20
> > > > * <code>exp</code>: represents a request expiration after which the=
 receiver reserves the right to broadcast the Fallback and ignore requests.
> > > >=20
> > > > BIP 78's BIP 21 payjoin parameters are also valid for version 2.
> > > >=20
> > > > =3D=3D=3DOptional sender parameters=3D=3D=3D
> > > >=20
> > > > When the payjoin sender posts the original PSBT to the receiver, it=
 can optionally specify the following HTTP query string parameters:
> > > >=20
> > > > * <code>v</code>: represents the version number of the payjoin prot=
ocol that the sender is using. This version is <code>2</code>.
> > > >=20
> > > > BIP 78's optional query parameters are also valid as version 2 para=
meters.
> > > >=20
> > > > =3D=3DRationale=3D=3D
> > > >=20
> > > > =3D=3D=3DRequest expiration & fallback=3D=3D=3D
> > > >=20
> > > > The relay may hold a request for an offline payjoin peer until that=
 peer comes online. However, the BIP 78 spec recommends broadcasting reques=
t PSBTs in the case of an offline counterparty. Doing so exposes a na?ve, s=
urveillance-vulnerable transaction which payjoin intends to avoid.
> > > >=20
> > > > The existing BIP 78 protocol has to be synchronous only for automat=
ed endpoints which may be vulnerable to probing attacks. It can cover this =
tradeoff by demanding a fallback transaction that would not preserve privac=
y the same way as a payjoin. BIP 21 URI can communicate a request expiratio=
n to alleviate both of these problems. Receivers may specify a deadline aft=
er which they will broadcast this fallback with a new expiration parameter =
<code>exp=3D</code>. <!-- I also like to for timeout, but it's hard to coor=
dinate in an asynchronous way -->
> > > >=20
> > > > =3D=3D=3DWebTransport=3D=3D=3D
> > > >=20
> > > > Many transport protocols are good candidates for Serverless Payjoin=
 functionality, but WebTransport stands out in its ability to stream and ta=
ke advantage of QUIC's performance in mobile environments. In developing th=
is BIP, serverless payjoin proofs of concept using TURN, HTTP/1.1 long poll=
ing, WebSockets, Magic Wormhole, and Nostr have been made. Streaming allows=
 the relay to have more granular and asynchronous understanding of the stat=
e of the peers, and this protcol is designed specifically to address the sh=
ortcomings of an HTTP protocol's requirement to receive from a reliable, al=
ways-online connection.
> > > >=20
> > > > While WebTransport and HTTP/3 it is built on are relatively new, wi=
despread support across browsers assures me that it is being accepted as a =
standard and even has a fallback to HTTP/2 environments. Being built on top=
 of QUIC allows it to multiplex connections from a relay to multiple peers =
which may prove advantageous for later payjoin protocols between more than =
two participants contributing inputs, such as those used to fund a lightnin=
g node with channels from multiple sources in one transaction, or those wit=
h threat models more similar to ZeroLink CoinJoin.
> > > >=20
> > > > While Nostr is fascinating from the perspective of censorship resis=
tance, the backwards compatibility with Payjoin v1 would mean only custom N=
ostr Payjoin relays exposing an https endpoint would be suitable. Nostr tra=
nsport is also limited by the performance of WebSockets, being an abstracti=
on on top of that protocol. If Nostr authentication were used instead of a =
symmetric <code>psk</code> then those keys would also need to be communicat=
ed out of band and complicate the protocol. There is nothing stopping a new=
 version of this protocol or a NIP making Payjoin version 2 possible over N=
ostr should Payjoin censorship become a bottleneck in the way of adoption.
> > > >=20
> > > > WebTransport is already shipped in both Firefox, Chrome, h3 in Rust=
, Go, and all popular languages. There is also [[https://w3c.github.io/p2p-=
webtransport/|a working draft for full P2P WebTransport]] without any relay=
, which a future payjoin protocol may make use of.
> > > >=20
> > > > =3D=3D=3DChaCha20Poly1305 AEAD=3D=3D=3D
> > > >=20
> > > > This authenticated encryption with additional data [[https://en.wik=
ipedia.org/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 a=
nd has high performance. ChaCha20Poly1305 AEAD seems to be making its way i=
nto bitcoin by way of [[https://github.com/bitcoin/bips/blob/master/bip-032=
4.mediawiki|BIP 324]] as well. The protocol has widespread support in brows=
ers, OpenSSL and libsodium. AES-GCM is more widespread but is both older, s=
lower, and not a dependency in bitcoin software.
> > > >=20
> > > > secp256k1 asymmetric cryptography could be used, but symmetric encr=
yption allows for many fewer messages to be sent, a single ephemeral key, a=
nd seems suitable given the one time use of BIP 21 URIs for Payjoin. Payjoi=
n already requires base64 encoding for PSBTs, so we have it available to en=
code the 256-bit <code>psk</code> in the BIP 21 parameter.
> > > >=20
> > > > =3D=3D=3DPSBT Version 2=3D=3D=3D
> > > >=20
> > > > The PSBT version 1 protocol was replaced because it was not designe=
d to have inputs and outputs be mutated. Payjoin mutates the PSBT, so BIP 7=
8 uses a hack where a new PSBT is created by the receiver instead of mutati=
ng it. This can cause some strange behaviors from signers who don't know wh=
ere to look to find the scripts that they are accountable for. PSBT version=
 2 makes mutating a PSBT's inputs and outputs trivial. It also eliminates t=
he transaction finalization step. Receivers who do not understand PSBT vers=
ion 1 may choose to reject Payjoin version 1 requests and only support PSBT=
 version 2.
> > > >=20
> > > > =3D=3D=3DAttack vectors=3D=3D=3D
> > > >=20
> > > > Since relays store arbitrary encrypted payloads to the tragedy of t=
he commons and denial of service attacks. Relay operators may impose an aut=
hentication requirement before they provide relay service to receivers to m=
itigate such attacks.
> > > >=20
> > > > Since <code>psk</code> is a symmetric key, the first message contai=
ning the sender's original PSBT does not have forward secrecy. Since relay =
buffers are associated with a single ephemeral relay directory, to support =
request-response simplicity of version 1, this seems appropriate.
> > > >=20
> > > > Since the Fallback PSBT is valid, even where <code>exp=3D</code> is=
 specified, the receiver may broadcast it and lose out on ambiguous privacy=
 protection from payjoin at any time. Though unfortunate, this is the typic=
al bitcoin transaction flow today anyhow.
> > > >=20
> > > > =3D=3D=3DNetwork privacy=3D=3D=3D
> > > >=20
> > > > Unlike BIP 78 implementations, sender and receiver peers will only =
see the IP address of the relay, not their peer's. Relays may be made avail=
able via Tor hidden service or Oblivious HTTP in addition to IP / DNS to al=
low either of the peers to protect their IP from the relay with without req=
uiring both peers to use additional network security dependencies.
> > > >=20
> > > > =3D=3DBackwards compatibility=3D=3D
> > > >=20
> > > > The receivers advertise payjoin capabilities through [[https://gith=
ub.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]].
> > > >=20
> > > > Senders not supporting payjoin will just ignore the <code>pj=3D</co=
de> parameter and proceed to typical address-based transaction flows. <code=
>req-pj=3D</code> may be used to compel payjoin.
> > > >=20
> > > > Receivers may choose to support version 1 payloads. Version 2 payjo=
in URIs should enable <code>pjos=3D0</code> so that these v1 senders disabl=
e output substitution since the v1 messages are neither encrypted nor authe=
nticated, putting them at risk for man-in-the-middle attacks otherwise. The=
 relay protocol should carry on as normal, validating based on HTTP headers=
 and constructing an unencrypted Version 2 payload from optional query para=
meters, and PSBT in the body.
> > > >=20
> > > > The BIP 78 error messages are already JSON formatted, so it made se=
nse to rely on the same dependency for these payloads and error messages.
> > > >=20
> > > > =3D=3DReference implementation=3D=3D
> > > >=20
> > > > An early proof of concept draft reference implementation can be fou=
nd at https://github.com/payjoin/rust-payjoin/pull/78. It implements an asy=
nchronous payment flow using WebSockets using PSBTv1 without encryption. An=
other reference can be found at https://github.com/payjoin/rust-payjoin/pul=
l/21 which uses HTTP long polling for transport and Noise NNpsk0 for crypto=
. Recently, I've come to realize the rationale for WebTransport, PSBTv2, an=
d ChaCha20-Poly1305 AEAD substitutions and am working on an implementation =
including this exact specification, but wanted to get early feedback on thi=
s design in the spirit of BIP 2.
> > > >=20
> > > > =3D=3DAcknowledgements=3D=3D
> > > >=20
> > > > Thank you to OpenSats for funding this pursuit, to Human Rights Fou=
ndation for putting a bounty on it and funding invaluable BOB Space space s=
upport, who I owe a thank you to as well. Thank you to Ethan Heilman, Nicol=
as Dorier, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, =
Mike Schmidt, Murch, D?vid Moln?r, Lucas Ontiviero, and uncountable twitter=
 plebs for feedback that has turned this idea from concept into draft, to M=
ike Jarmuz for suggesting that I write a BIP, and to Satsie for writing the=
 "All About BIPS" zine which I've referenced a number of times in the draft=
ing process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for hac=
king on the first iOS Payjoin receiver and uncovering the problem that this=
 solves in the first place.
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >=20
> > ------------------------------
> >=20
> > Subject: Digest Footer
> >=20
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >=20
> > ------------------------------
> >=20
> > End of bitcoin-dev Digest, Vol 99, Issue 25
> > *******************************************
>=20
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev