path: root/61/597fe0e8f43d62c54ff4d061054d43d74c482b

Return-Path: <d@ngould.dev>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4E69DC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Aug 2023 17:13:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 1356840567
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Aug 2023 17:13:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1356840567
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=ShZs7WRo
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.067
X-Spam-Level: 
X-Spam-Status: No, score=-0.067 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,
 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 aw5hNNcvQc2G
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Aug 2023 17:13:16 +0000 (UTC)
X-Greylist: delayed 601 seconds by postgrey-1.37 at util1.osuosl.org;
 Fri, 11 Aug 2023 17:13:16 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5C93240186
Received: from mail-4327.protonmail.ch (mail-4327.protonmail.ch [185.70.43.27])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 5C93240186
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Aug 2023 17:13:16 +0000 (UTC)
Date: Fri, 11 Aug 2023 17:03:02 +0000
Authentication-Results: mail-4321.protonmail.ch;
 dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev
 header.b="ShZs7WRo"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ngould.dev;
 s=protonmail; t=1691773391; x=1692032591;
 bh=lRF6pvpV7Klr7wCBY4/P5qWvvbMvnf9NhhxtM8z9c7U=;
 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=ShZs7WRoeZ+qgPZ8gdq9yeowvn+MDjQxaUAF/h52/k4iMCzS2zoOy4l62MHeWsHhp
 dcYt2S+/k85SlWqeQseQIUq5CrqdJpem2Xk7kqtIRlQEN5FOhXbJ1sozn3rCFi0NUj
 oknKASaAkxXFt6mtvj6hBDEJbwgl3FZ4ytuJ1bjQ=
To: bitcoin-dev@lists.linuxfoundation.org, AdamISZ <adamisz@protonmail.com>
From: Dan Gould <d@ngould.dev>
Message-ID: <50A19B79-46A1-4F21-AA53-74356F4B0CBA@ngould.dev>
In-Reply-To: <mailman.130337.1691684480.956.bitcoin-dev@lists.linuxfoundation.org>
References: <mailman.130337.1691684480.956.bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 11 Aug 2023 21:37:12 +0000
Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin (AdamISZ)
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: Fri, 11 Aug 2023 17:13:19 -0000

Hi waxwing

thanks for the detailed response. You've identified a number of flaws both =
in the protocol and the document that can be fixed. I sincerely appreciate =
it. If more comes to mind, fire away.

> I wanted to immediately "nit" a point I saw as I was reading:
>=20
>> Because BIP 78 messages are neither authenticated nor encrypted a malici=
ous unsecured payjoin server is able to modify the Payjoin PSBT in flight,
>=20
> Taken as is - i.e. out of context! - this is just wrong. The BIP explicit=
ly states:
>=20
> "The sender must ensure that the url refers to a scheme or protocol using=
 authenticated encryption, for example TLS with certificate validation, or =
a .onion link to a hidden service whose public key identifier has already b=
een communicated via a TLS connection. Senders SHOULD NOT accept a url repr=
esenting an unencrypted or unauthenticated connection. "

Nice Catch. I've fixed it in the draft.

> Out of band, the receiver of the payment, shares a bitcoin URI with the s=
ender including a <code>pj=3D</code> query parameter describing the relay s=
ubdirectory endpoint and <code>psk=3D</code> parameter with base64 encoded =
256-bit secret key.

> You're sending the symmetric secret key out of band; but isn't this obscu=
ring the question of securely sharing the secret key? Did you consider DH-i=
ng this as other protocols do? At the very least I would claim that it's li=
kely that implementers might be sloppy here; at the most I would claim this=
 is just insecure full stop.

At first I thought this would be secure because the relay itself would need=
 to discover the key only to uncover privacy, but because of output substit=
ution it would actually open the protocol to a loss of funds attack: If the=
 ask-containing bip21 were discovered by the relay, then the relay would ha=
ve enough information to both find the buffer and forge a Payjoin PSBT payi=
ng itself rather than the receiver, and the sender would send it because ou=
tput substitution is allowed. Even though I handle bip21s and addresses as =
secret, I know many people post them in unencrypted channels and so they sh=
ould not be assumed secure to pass secrets.

I have certainly considered the security trade offs of using a symmetric ke=
y vs DH. The main reason I chose to use the symmetric psk over DH is becaus=
e I thought DH would require another round of communication to establish re=
ceiver authentication, which is a huge inconvenience in an asynchronous set=
ting. The attack I=E2=80=99ve described can be mitigated inside the same me=
ssage pattern by having receiver share a public key of a per-request keypai=
r Instead, approximately following the NKpsk0 pattern, the sender may pass =
an ephemeral secret session key under which the Payjoin PSBT response would=
 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 for=
 this purpose, but I see no reason to tie buffer identity to the underlying=
 wallet. Using ephemeral keys also allows a single receiver to enroll multi=
ple buffers at a relay simultaneously.

> About attack vectors:
>=20
> Since relays store arbitrary encrypted payloads to the tragedy of the com=
mons and denial of service attacks. Relay operators may impose an authentic=
ation requirement before they provide relay service to receivers to mitigat=
e such attacks.
>=20
> 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. *=
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 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?

The most obvious concern with this architecture is indeed that the relays w=
ould have metadata that could be used for timing attacks correlating to a P=
ayjoin PSBT buffer being cleared from the relay and a potential payjoin tra=
nsaction being broadcast. If a sufficient number of steganographic transact=
ions are broadcast per quantum, then requiring a sender to broadcast only a=
fter a random delay based on a poisson distribution could mitigate this pro=
blem somewhat. According to S. Ghesmati 2020 research, between 27% and 42% =
of all transactions conform to the type of unnecessary input heuristic that=
 payjoins conform to (UIH2). So it wouldn=E2=80=99t take long for multiple =
steganographic candidates to enter the Mempool at any given time.

I'm extremely reluctant to require Tor because it severely limits the numbe=
r of environments where this proposal could be deployed. If we were to requ=
ire Tor, we should then just ignore this proposal and focus on deploying hi=
dden service based v1 receivers as in JoinMarket. I'm more inclined to requ=
ire Oblivious HTTP but even that seems overkill when the threat would be fo=
r the relay to correlate steganographic transactions, which don't have a si=
ngle clear sender/receiver interpretation, to two ip addresses.

> It just occurred to me that while timing correlation itself might not be =
much (in usual circumstances, there are tons of other transactions), it's, =
as usual with metadata, the intersection of more than one thing that could =
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).

The biggest intersection attack is timing correlation of two linked potenti=
al payjoin transactions related to one IP address. Again, a specified delay=
 may help mitigate this concern.

I agree that padding ought to be a requirement. 4M block size limit with ba=
se64 encoding overhead seems like a resonable buffer size, but PSBTs have s=
ignificant overhead compared to consensus transactions, so the exact size o=
f a buffer needs more attention.

Thanks for the feedback,
Dan

> 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
>=20
> Today's Topics:
>=20
>  1. Re: BIP for Serverless Payjoin (AdamISZ)
>=20
>=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-nrMvjYmBobfYzbRrF37QztsuAVdM6HSZJ8UH=
l27QKYAWq0zYQMmYnBmg0YE-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 be =
much (in usual circumstances, there are tons of other transactions), it's, =
as usual with metadata, the intersection of more than one thing that could =
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 relays h=
ave metadata - most obviously, they can time correlate messages, with bitco=
in network events, so at the least they could tie transactions to clients. =
If both parties use anonymised network connections then this is ameliorated=
 (though not removed) as a vector, but then we'd need to be clear that we r=
equire those (e.g. Tor). Not sure if it's palatable to do this if otherwise=
, i.e. if we think the relays can tie network addresses to transactions? We=
ll, 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 bitco=
in-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?m sharing an interme=
diate draft of the BIP here before opening a draft on GitHub for the BIP ed=
itors, and before this exact specification has a complete reference impleme=
ntation. The draft does reference two proof of concept payjoin implementati=
ons, one demonstrating use of symmetric cryptography, and the other asynchr=
onous messaging and backwards compatibility.
>>>=20
>>> I?ve updated the Serverless Payjoin gist to reflect this draft specific=
ation 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 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?ve, surve=
illance-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?vid Moln?r, Lucas Ontiviero, and uncountable twitter ple=
bs for feedback that has turned this idea from concept into draft, to Mike =
Jarmuz for suggesting that I write a BIP, and to Satsie for writing the "Al=
l About BIPS" zine which I've referenced a number of times in the drafting =
process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for hacking=
 on the first iOS Payjoin receiver and uncovering the problem that this sol=
ves in the first place.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=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
> ------------------------------
>=20
> End of bitcoin-dev Digest, Vol 99, Issue 25
> *******************************************