summaryrefslogtreecommitdiff
path: root/aa/6f0b57b04a4ac42bc30aafa02bc41cf9761488
blob: 5e985fa8fcf98f949056ef637b4f0fb42004a63a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
Return-Path: <AdamISZ@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CB799C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 15:38:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id A0BAC417B7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 15:38:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A0BAC417B7
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=mQRzu4KC
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.064
X-Spam-Level: 
X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 LONGWORDS=2.035, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0bKsjiMRFVnf
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 15:38:03 +0000 (UTC)
X-Greylist: delayed 2453 seconds by postgrey-1.37 at util1.osuosl.org;
 Thu, 10 Aug 2023 15:38:02 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C70DB404AE
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
 [185.70.40.134])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C70DB404AE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 15:38:02 +0000 (UTC)
Date: Thu, 10 Aug 2023 15:37:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1691681878; x=1691941078;
 bh=8dTiEf9QjaOCaw35cqh5AYAOt/FG01gVRH4V/usoOPw=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=mQRzu4KCm4Kw6Z1+XQSLMASgu9EA6AL3EpDEkJfZ9sZFsrLjQvHrrMhvy67SkcyO1
 Dcp763wuqTT0nXwvSGEu7v6gwmn0EBHxrdjCzHERAG/wY5Xfssatmlnfzr6fzML+bu
 55WtaQys1pmjKAO0Jjoci2fyRvzXp1OniNcPWjqNzqhg810S7NOE2L+uCjwPvKmaZe
 aers/rVtxFpKg7EjpCWjGNtpc8akKJDto/o13wIBQiU0sYUlnN6aeXyU1pDIb7mBV0
 HWmE3Pt9Mym6i1a9DVl4U+/K/cA8Vo9s9GMlaTIGBD3xk60JZhzA2Cfy9eiGXFJpRT
 b71ruQWHt3B6w==
To: Dan Gould <d@ngould.dev>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <qUoIvwrIl8ltj3TkQ7y1ExhjUan6VEpGl7c7TlHNfF1pT-eZWd_mwuNYH13YPRyvMj9OSApLmW-hwrdaHCEapEXr503SlXSywcAGceXcbow=@protonmail.com>
In-Reply-To: <7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev>
References: <7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 10 Aug 2023 16:21:20 +0000
Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2023 15:38:05 -0000

Hi Dan,
A couple more more thoughts:

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

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

About attack vectors:

> Since relays store arbitrary encrypted payloads to the tragedy of the com=
mons and denial of service attacks. Relay operators may impose an authentic=
ation requirement before they provide relay service to receivers to mitigat=
e such attacks.

Isn't the most obvious concern with this architecture, that the relays have=
 metadata - most obviously, they can time correlate messages, with bitcoin =
network events, so at the least they could tie transactions to clients. *If=
* both parties use anonymised network connections then this is ameliorated =
(though not removed) as a vector, but then we'd need to be clear that we *r=
equire* those (e.g. Tor). Not sure if it's palatable to do this if otherwis=
e, i.e. if we think the relays can tie network addresses to transactions? W=
ell, not sure, but I'd expect it to be mentioned?

Cheers,
AdamISZ/waxwing


Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, August 9th, 2023 at 11:32, Dan Gould via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:


> Hi all,
>=20
> The Serverless Payjoin idea has come a long way toward formal specificati=
on of a Payjoin version 2. In the spirit of BIP 2, I=E2=80=99m sharing an i=
ntermediate draft of the BIP here before opening a draft on GitHub for the =
BIP editors, and before this exact specification has a complete reference i=
mplementation. The draft does reference two proof of concept payjoin implem=
entations, one demonstrating use of symmetric cryptography, and the other a=
synchronous messaging and backwards compatibility.
>=20
> I=E2=80=99ve updated the Serverless Payjoin gist to reflect this draft sp=
ecification https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32=
f9 in order to preserve the edit history before opening a bips PR.
>=20
> The specifics have changed significantly compared to the first mailing li=
st post to reflect feedback. Looking forward to hear your thoughts.
>=20
> Dan
>=20
> <pre>
>=20
> BIP: ???
> Layer: Applications
> Title: Payjoin Version 2: Serverless Payjoin
> Author: Dan Gould d@ngould.dev
>=20
> Status: Draft
> Replaces: 78
> Type: Standards Track
> Created: 2023-08-08
> License: BSD-2-Clause
> </pre>
>=20
>=20
> =3D=3DAbstract=3D=3D
>=20
> This document proposes a backwards-compatible second version of the payjo=
in protocol described in [[bip-0078.mediawiki|BIP 78]], allowing complete p=
ayjoin receiver functionality including payment output substitution without=
 requiring them to host a secure public endpoint. This requirement is repla=
ced with an untrusted third-party relay and streaming clients which communi=
cate using an asynchronous protocol and authenticated encrypted payloads.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the 2-clause BSD license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Payjoin solves the sole privacy problem left open in the bitcoin paper, t=
hat transactions with multiple inputs "necessarily reveal that their inputs=
 were owned by the same owner." Breaking that common-input ownership assump=
tion and others requires input from multiple owners. Cooperative transactio=
n construction also increases transaction throughput by providing new oppor=
tunity for payment batching and transaction cut-through.
>=20
> Version 1 coordinates payjoins over a public server endpoint secured by e=
ither TLS or Tor onion hidden service hosted by the receiver. Version 1 is =
synchronous, so both sender and reciever must be online simultaneously to p=
ayjoin. Both requirements present significant barriers for all but sophisti=
cated server operators or those wallets with complex Tor integration. These=
 barriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
1-January/018358.html|regarded]] as limits to payjoin adoption.
>=20
> The primary goal of this proposal is to provide a practical coordination =
mechanism to be adopted in a vast majority of wallet environments. This is =
realized as a simple protocol built on bitcoin URI requests, web standards,=
 common crypto, and minimal dependencies.
>=20
> =3D=3D=3DRelation to BIP 78 (Payjoin version 1)=3D=3D=3D
>=20
> The message payloads in this version parrallel those used in BIP 78 while=
 being encapsulated in authenticated encryption, forgoing HTTP messaging fo=
r WebTransport streaming of asynchronus interactions, and leveraging PSBT v=
ersion 2.
>=20
> The BIP 78 standard allows for an [[https://github.com/bitcoin/bips/blob/=
master/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin server=
|]] to operate separately from the so-called "payment server" responsible f=
or generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediaw=
iki|BIP 21]] request URIs. Because BIP 78 messages are neither authenticate=
d nor encrypted a malicious unsecured payjoin server is able to modify the =
Payjoin PSBT in flight, thus requiring [[payment output substitition]] to b=
e disabled. Output substitition is useful for a number of block space optim=
izations, including payment batching and transaction cut-through. This prop=
osal introduces authentication and encryption to secure output substition w=
hile using a relay without compromising sender or receiver privacy.
>=20
> Although unsecured payjoin server separation is mentioned in BIP 78, no k=
nown specification or implementation of one exists. This document specifies=
 one to be backwards compatible with version 1 senders. Receivers respondin=
g to version 1 senders must disable output substitution their payloads are =
plaintext so they may payjoin without the risk of the relay stealing funds.
>=20
> The protocols in this document reuse BIP 78's BIP 21 URI parameters. A Fa=
llback PSBT timeout parameter is introduced which may also help coordinate =
the synchronous version 1 protocol.
>=20
> =3D=3D=3DRelation to Stowaway=3D=3D=3D
>=20
> [[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoots/STOW=
AWAY.md|Stowaway]] is a payjoin coordination mechanism which depends on Tor=
, a third-party relay, and the [[https://samouraiwallet.com/paynym|PayNym]]=
 [[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki|BIP 47]] =
Payment codes directory for subdirectory identification and encryption. The=
 payjoin version 2 protocol uses one-time symmetric keys for relay subdirec=
tory identification, authentication, and encryption instead of BIP 47 publi=
c keys derived from the wallet. Payjoin version 2 also supports asynchronou=
s messaging, in contrast to online Stowaway's synchronous HTTP-based messag=
ing. Offline stowaway may depends on manual message passing rather than an =
asynchronous network protocol. Successful Stowaway execution results in 2-o=
utput transactions, while BIP 79, 78, and this work may produce batched tra=
nsactions with many outputs.
>=20
> =3D=3DSpecification=3D=3D
>=20
> =3D=3D=3DOverview=3D=3D=3D
>=20
> Payjoin requests are made using familiar BIP 21 URIs. Instead of a public=
 HTTP endpoint, this scheme allows a WebTransport client to enroll with a r=
elay server to receive payjoin. Relays may optionally require an authorizat=
ion credential before allocating resources in order to prevent DoS attacks.=
 Sender and receiver payloads are buffered at the relay to support asynchro=
nous interaction. Symmetric authenticated encryption (ChaCha20-Poly1305 AEA=
D) prevents the relay from snooping on message contents or forging messages=
. Aside from a pre-shared secret and relayed asynchronus networking, the ve=
rsion 2 messaging takes much the same form as the existing BIP 78 specifica=
tion.
>=20
> =3D=3D=3DBasic scheme=3D=3D=3D
>=20
> The recipient first generates a 256-bit key <code>psk</code>. This pre-sh=
ared key will be the basis of end-to-end authenticated encryption and ident=
ification of a particular payjoin over the relay.
>=20
>=20
> Rather than hosting a public server, they start a streaming session to re=
ceive messages and allocate a subdirectory from which to relay messages. Th=
e first message must include the first 4 bytes of the Sha256 hash of their =
<code>psk</code> to be enrolled as a subdirectory identifier. The next mess=
age streamed from the relay to sender includes the enrolled subdirectory pa=
yjoin endpoint. After enrollment, they await a payjoin request on a session=
 identified by the subdirectory. Out of band, the receiver shares a [[https=
://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] payjoin =
uri including the relay endpoint in the <code>pj=3D</code> query parameter =
and the pre-shared key in a new <code>psk=3D</code> query parameter.
>=20
>=20
> The sender constructs an encrypted and authenticated payload containing a=
 PSBT and optional parameters similar to BIP 78. The resulting ciphertext e=
nsures message secrecy and integrity when streamed to the recipient by the =
relay-hosted subdirectory <code>pj=3D</code> endpoint.
>=20
>=20
> The sender's request is relayed to the receiver over a streaming session =
at the subdirectory identified by the hash of <code>psk</code>. Messages ar=
e secured by symmetric cipher rather than TLS or Onion routing session key.=
 Sender and receiver may experience network interruption and proceed with t=
he protocol since their request and response are buffered at the Payjoin re=
lay subdirectory.
>=20
>=20
> =3D=3D=3DPayjoin version 2 messaging=3D=3D=3D
>=20
> Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/master/bip=
-0370.mediawiki|BIP 370 PSBT v2]] format to fascilitate PSBT mutation.
>=20
> The payjoin version 2 protocol takes the following steps:
>=20
> * The recipient sends the first 4 bytes of <code>H(psk)</code> and option=
al authentication credential according to [[#receiver-relay-enrollment|rece=
iver relay enrollment]] protocol. It may go offline and replay enrollment t=
o come back online.
>=20
> * Out of band, the receiver of the payment, shares a bitcoin URI with the=
 sender including a <code>pj=3D</code> query parameter describing the relay=
 subdirectory endpoint and <code>psk=3D</code> parameter with base64 encode=
d 256-bit secret key. To support version 1 senders the relay acts as an uns=
ecured payjoin server so <code>pjos=3D0</code> must be specified in the URI=
. Version 2 senders may safely allow output substitution regardless.
>=20
> * The sender creates a valid PSBT according to [[https://github.com/bitco=
in/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiver=
 checklist]] formatted as PSBTv2. We call this the <code>Fallback PSBT</cod=
e>. This Fallback PSBT and optional sender parameters are encrypted and aut=
henticated with the <code>psk</code> using ChaCha20Poly1305 and streamed to=
 the relay subdirectory endpoint.
>=20
> * The sender awaits a response from the relay stream containing an encryp=
ted <code>Payjoin PSBT</code>. It can replay the <code>Fallback PSBT</code>=
 to request a response if it goes offline.
>=20
> * The request is stored in the receiver's subdirectory buffer.
> * Once the receiver is online, it awaits a stream of request updates from=
 the relay. The receiver decrypts aund authenticates the payload then check=
s it according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#re=
ceivers-original-psbt-checklist|the receiver checklist]]. It updates it to =
include new signed inputs and outputs invalidating sender signatures, and m=
ay adjust the fee. We call this the <code>Payjoin PSBT</code>.
>=20
> * It responds with the <code>Payjoin PSBT</code> encrypted then authentic=
ated under <code>psk</code> using ChaCha20Poly1305.
>=20
> * The relay awaits a connection from the sender if it goes offline. Upon =
connection, it relays the encrypted <code>Payjoin PSBT</code> to the sender=
.
>=20
> * The sender validates the <code>Payjoin PSBT</code> according to [[#send=
ers-payjoin-psbt-checklist|the sender checklist]], signs its inputs and bro=
adcasts the transaction to the Bitcoin network.
>=20
>=20
> The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as bytes.
>=20
> The Fallback PSBT MUST:
>=20
> * Include complete UTXO data.
> * Be signed.
> * Exclude unnecessary fields such as global xpubs or keypath information.=
 <!-- I believe PSBTv2 obviates this requirement -->
>=20
> * Set input and output Transaction Modifiable Flags to 1
> * Be broadcastable.
>=20
> The Fallback PSBT MAY:
>=20
> * Include outputs unrelated to the sender-receiver transfer for batching =
purposes.
> * Set SIGHASH_SINGLE Transaction Modifiable Flags flags to 1
>=20
> The Payjoin PSBT MUST:
>=20
> * Include all inputs from the Fallback PSBT.
> * Include all outputs which do not belong to the receiver from the Fallba=
ck PSBT.
> * Include complete UTXO data.
>=20
> The Payjoin PSBT sender MAY:
>=20
> * Add, remove or modify Fallback PSBT outputs under the control of the re=
ceiver (i.e. not sender change).
>=20
> The Payjoin PSBT MUST NOT:
>=20
> * Shuffle the order of inputs or outputs; the additional outputs or addit=
ional inputs must be inserted at a random index.
> * Decrease the absolute fee of the original transaction.
>=20
> =3D=3D=3DReceiver's Payjoin PSBT checklist=3D=3D=3D
>=20
> Other than requiring PSBTv2 the receiver checklist is the same as the [[h=
ttps://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-ori=
ginal-psbt-checklist|the BIP 78 receiver checklist]]
>=20
> =3D=3D=3DSender's Payjoin PSBT checklist=3D=3D=3D
>=20
> The version 2 sender's checklist is largely the same as the [[https://git=
hub.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-checklis=
t|the BIP 78 checklist]] with the exception that it expects ALL utxo data t=
o be filled in. BIP 78 required sender inputs UTXO data to be excluded from=
 the PSBT which has caused many headaches since it required the sender to a=
dd them back to the Payjoin proposal PSBT. Version 2 has no such requiremen=
t.
>=20
> =3D=3D=3DRelay interactions=3D=3D=3D
>=20
> The Payjoin Relay provides a rendezvous point for sender and receiver to =
meet. It stores Payjoin payloads to support asynchronous communication. It =
is available on the open internet over HTTPS to accept both WebTransport fo=
r Payjoin version 2, accepting encrypted payloads, and optionally HTTP/1.1 =
to support backwards compatible Payjoin version 1 requests.
>=20
> =3D=3D=3DReceiver interactions=3D=3D=3D
>=20
> =3D=3D=3D=3DRelay enrollment=3D=3D=3D=3D
>=20
> Receivers must enroll to have resources allocated on a relay. Sessions ma=
y begin by having a receiver send the first 4 bytes of the Sha256 hash of t=
heir <code>psk</code> to the relay. The receiver returns the subdirectory e=
ndpoint url. Enrollment may be replayed in case the receiver goes offline.
>=20
>=20
> Optionally, before returning the uri the receiver may request an authenti=
cation token by presenting a message containing only the word <code>Authent=
icate: <description></code> after which the receiver is required to submit =
an <code>Authenticate: <token></code> including the token from the Relay ou=
t of band. If authentication fails an error is returned.
>=20
>=20
> In the case a relay is operated by an exchange, it may give out authentic=
ation tokens for users of its app, or may require some proof of work out of=
 band. Tokens should be anonymous credentials from the relay describing the=
 parameters of their authorization. Specific credentialing is out of the sc=
ope of this proposal.
>=20
> =3D=3D=3D=3DReceiver Payjoin PSBT response=3D=3D=3D=3D
>=20
> The receiver streams the base64 Payjoin PSBT as encrypted bytes from ChaC=
ha20Poly1305 under <code>psk</code>.
>=20
>=20
> =3D=3D=3DSender interactions=3D=3D=3D
>=20
> The sender starts a WebTransport session with the relay at the Payjoin en=
dpoint URI provided by the receiver. It sends the following payload and awa=
its a relayed response payload from the receiver.
>=20
> =3D=3D=3D=3DVersion 2 Fallback PSBT request=3D=3D=3D=3D
>=20
> The version 2 Fallback PSBT Payload is constructed in JSON before being e=
ncrypted as follows.
>=20
> <pre>
>=20
> {
> "psbt": "<fallback_psbt_data_base64>",
>=20
> "params": {
> "param1": "<value1>",
>=20
> "param2": "<value1>",
>=20
> ...
> }
> }
> </pre>
>=20
>=20
> The payload must be encrypted using ChaCha20Poly1305 by the sender using =
the <code>psk</code>.
>=20
>=20
> =3D=3D=3D=3DVersion 1 Fallback PSBT request=3D=3D=3D=3D
>=20
> The message should be the same as version 2 but unencrypted, as version 1=
 is unaware of encryption when using an unsecured payjoin server. The Relay=
 should convert the PSBT to PSBTv2 and construct the JSON payload from the =
HTTP request body and optional query parameters. Upon receiving an unencryp=
ted PSBTv2 response from a receiver, it should convert it to PSBTv0 for com=
patibility with BIP 78.
>=20
> =3D=3D=3DAsynchronous relay buffers=3D=3D=3D
>=20
> Each receiver subdirectory on the relay server has a buffer for requests =
and one for responses. Each buffer updates listeners through awaitable even=
ts so that updates are immediately apparent to relevant client sessions.
>=20
> =3D=3D=3DBIP 21 receiver parameters=3D=3D=3D
>=20
> A major benefit of BIP 78 payjoin over other coordination mechanisms is i=
ts compatibility with the universal BIP 21 bitcoin URI standard.
>=20
> This proposal defines the following new [[https://github.com/bitcoin/bips=
/blob/master/bip-0021.mediawiki|BIP 21 URI]] parameters:
>=20
> * <code>psk</code>: the pre-shared symmetric key for encryption and authe=
ntication with ChaCha20-Poly1305
>=20
> * <code>exp</code>: represents a request expiration after which the recei=
ver reserves the right to broadcast the Fallback and ignore requests.
>=20
>=20
> BIP 78's BIP 21 payjoin parameters are also valid for version 2.
>=20
> =3D=3D=3DOptional sender parameters=3D=3D=3D
>=20
> When the payjoin sender posts the original PSBT to the receiver, it can o=
ptionally specify the following HTTP query string parameters:
>=20
> * <code>v</code>: represents the version number of the payjoin protocol t=
hat the sender is using. This version is <code>2</code>.
>=20
>=20
> BIP 78's optional query parameters are also valid as version 2 parameters=
.
>=20
> =3D=3DRationale=3D=3D
>=20
> =3D=3D=3DRequest expiration & fallback=3D=3D=3D
>=20
> The relay may hold a request for an offline payjoin peer until that peer =
comes online. However, the BIP 78 spec recommends broadcasting request PSBT=
s in the case of an offline counterparty. Doing so exposes a na=C3=AFve, su=
rveillance-vulnerable transaction which payjoin intends to avoid.
>=20
> The existing BIP 78 protocol has to be synchronous only for automated end=
points which may be vulnerable to probing attacks. It can cover this tradeo=
ff by demanding a fallback transaction that would not preserve privacy the =
same way as a payjoin. BIP 21 URI can communicate a request expiration to a=
lleviate both of these problems. Receivers may specify a deadline after whi=
ch they will broadcast this fallback with a new expiration parameter <code>=
exp=3D</code>. <!-- I also like to for timeout, but it's hard to coordinate=
 in an asynchronous way -->
>=20
>=20
> =3D=3D=3DWebTransport=3D=3D=3D
>=20
> Many transport protocols are good candidates for Serverless Payjoin funct=
ionality, but WebTransport stands out in its ability to stream and take adv=
antage of QUIC's performance in mobile environments. In developing this BIP=
, serverless payjoin proofs of concept using TURN, HTTP/1.1 long polling, W=
ebSockets, Magic Wormhole, and Nostr have been made. Streaming allows the r=
elay to have more granular and asynchronous understanding of the state of t=
he peers, and this protcol is designed specifically to address the shortcom=
ings of an HTTP protocol's requirement to receive from a reliable, always-o=
nline connection.
>=20
> While WebTransport and HTTP/3 it is built on are relatively new, widespre=
ad support across browsers assures me that it is being accepted as a standa=
rd and even has a fallback to HTTP/2 environments. Being built on top of QU=
IC allows it to multiplex connections from a relay to multiple peers which =
may prove advantageous for later payjoin protocols between more than two pa=
rticipants contributing inputs, such as those used to fund a lightning node=
 with channels from multiple sources in one transaction, or those with thre=
at models more similar to ZeroLink CoinJoin.
>=20
> While Nostr is fascinating from the perspective of censorship resistance,=
 the backwards compatibility with Payjoin v1 would mean only custom Nostr P=
ayjoin relays exposing an https endpoint would be suitable. Nostr transport=
 is also limited by the performance of WebSockets, being an abstraction on =
top of that protocol. If Nostr authentication were used instead of a symmet=
ric <code>psk</code> then those keys would also need to be communicated out=
 of band and complicate the protocol. There is nothing stopping a new versi=
on of this protocol or a NIP making Payjoin version 2 possible over Nostr s=
hould Payjoin censorship become a bottleneck in the way of adoption.
>=20
>=20
> WebTransport is already shipped in both Firefox, Chrome, h3 in Rust, Go, =
and all popular languages. There is also [[https://w3c.github.io/p2p-webtra=
nsport/|a working draft for full P2P WebTransport]] without any relay, whic=
h a future payjoin protocol may make use of.
>=20
> =3D=3D=3DChaCha20Poly1305 AEAD=3D=3D=3D
>=20
> This authenticated encryption with additional data [[https://en.wikipedia=
.org/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 and has=
 high performance. ChaCha20Poly1305 AEAD seems to be making its way into bi=
tcoin by way of [[https://github.com/bitcoin/bips/blob/master/bip-0324.medi=
awiki|BIP 324]] as well. The protocol has widespread support in browsers, O=
penSSL and libsodium. AES-GCM is more widespread but is both older, slower,=
 and not a dependency in bitcoin software.
>=20
> secp256k1 asymmetric cryptography could be used, but symmetric encryption=
 allows for many fewer messages to be sent, a single ephemeral key, and see=
ms suitable given the one time use of BIP 21 URIs for Payjoin. Payjoin alre=
ady requires base64 encoding for PSBTs, so we have it available to encode t=
he 256-bit <code>psk</code> in the BIP 21 parameter.
>=20
>=20
> =3D=3D=3DPSBT Version 2=3D=3D=3D
>=20
> The PSBT version 1 protocol was replaced because it was not designed to h=
ave inputs and outputs be mutated. Payjoin mutates the PSBT, so BIP 78 uses=
 a hack where a new PSBT is created by the receiver instead of mutating it.=
 This can cause some strange behaviors from signers who don't know where to=
 look to find the scripts that they are accountable for. PSBT version 2 mak=
es mutating a PSBT's inputs and outputs trivial. It also eliminates the tra=
nsaction finalization step. Receivers who do not understand PSBT version 1 =
may choose to reject Payjoin version 1 requests and only support PSBT versi=
on 2.
>=20
> =3D=3D=3DAttack vectors=3D=3D=3D
>=20
> Since relays store arbitrary encrypted payloads to the tragedy of the com=
mons and denial of service attacks. Relay operators may impose an authentic=
ation requirement before they provide relay service to receivers to mitigat=
e such attacks.
>=20
> Since <code>psk</code> is a symmetric key, the first message containing t=
he sender's original PSBT does not have forward secrecy. Since relay buffer=
s are associated with a single ephemeral relay directory, to support reques=
t-response simplicity of version 1, this seems appropriate.
>=20
>=20
> Since the Fallback PSBT is valid, even where <code>exp=3D</code> is speci=
fied, the receiver may broadcast it and lose out on ambiguous privacy prote=
ction from payjoin at any time. Though unfortunate, this is the typical bit=
coin transaction flow today anyhow.
>=20
>=20
> =3D=3D=3DNetwork privacy=3D=3D=3D
>=20
> Unlike BIP 78 implementations, sender and receiver peers will only see th=
e IP address of the relay, not their peer's. Relays may be made available v=
ia Tor hidden service or Oblivious HTTP in addition to IP / DNS to allow ei=
ther of the peers to protect their IP from the relay with without requiring=
 both peers to use additional network security dependencies.
>=20
> =3D=3DBackwards compatibility=3D=3D
>=20
> The receivers advertise payjoin capabilities through [[https://github.com=
/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]].
>=20
> Senders not supporting payjoin will just ignore the <code>pj=3D</code> pa=
rameter and proceed to typical address-based transaction flows. <code>req-p=
j=3D</code> may be used to compel payjoin.
>=20
>=20
> Receivers may choose to support version 1 payloads. Version 2 payjoin URI=
s should enable <code>pjos=3D0</code> so that these v1 senders disable outp=
ut substitution since the v1 messages are neither encrypted nor authenticat=
ed, putting them at risk for man-in-the-middle attacks otherwise. The relay=
 protocol should carry on as normal, validating based on HTTP headers and c=
onstructing an unencrypted Version 2 payload from optional query parameters=
, and PSBT in the body.
>=20
>=20
> The BIP 78 error messages are already JSON formatted, so it made sense to=
 rely on the same dependency for these payloads and error messages.
>=20
> =3D=3DReference implementation=3D=3D
>=20
> An early proof of concept draft reference implementation can be found at =
https://github.com/payjoin/rust-payjoin/pull/78. It implements an asynchron=
ous payment flow using WebSockets using PSBTv1 without encryption. Another =
reference can be found at https://github.com/payjoin/rust-payjoin/pull/21 w=
hich uses HTTP long polling for transport and Noise NNpsk0 for crypto. Rece=
ntly, I've come to realize the rationale for WebTransport, PSBTv2, and ChaC=
ha20-Poly1305 AEAD substitutions and am working on an implementation includ=
ing this exact specification, but wanted to get early feedback on this desi=
gn in the spirit of BIP 2.
>=20
> =3D=3DAcknowledgements=3D=3D
>=20
> Thank you to OpenSats for funding this pursuit, to Human Rights Foundatio=
n for putting a bounty on it and funding invaluable BOB Space space support=
, who I owe a thank you to as well. Thank you to Ethan Heilman, Nicolas Dor=
ier, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, Mike S=
chmidt, Murch, D=C3=A1vid Moln=C3=A1r, Lucas Ontiviero, and uncountable twi=
tter plebs for feedback that has turned this idea from concept into draft, =
to Mike Jarmuz for suggesting that I write a BIP, and to Satsie for writing=
 the "All About BIPS" zine which I've referenced a number of times in the d=
rafting process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for=
 hacking on the first iOS Payjoin receiver and uncovering the problem that =
this solves in the first place.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev