Date: Sun, 22 Jan 2023 20:50:44 +0000
To: bitcoin-dev@lists.linuxfoundation.org
From: Dan Gould <d@ngould.dev>
Message-ID: <3C0A6E4C-444E-4E75-829C-1A21D8EE40E0@ngould.dev>
Feedback-ID: 13175031:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Serverless Payjoin
Precedence: list


Hi all,

I'm publishing a payjoin upgrade in response to a request from this list. T=
he payjoin receiver no longer has to run a public server. They lean on a re=
lay for the connection and share a symmetric-key for security rather than a=
 TLS certificate or a Tor hidden service.

I think this work raises a greater problem which is that payjoin assumes sy=
nchronous communication while it=E2=80=99s an asynchronous world.

I added the full write-up in plain text below, though I recommend reading t=
he gist for improved formatting and in order to benefit from future edits:
https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9

Best regards,
Dan


Serverless Payjoin


Receive surveillance-busting bitcoin transfers without hosting a secure end=
point


OVERVIEW


Payjoin[1] solves the sole privacy problem left open in the bitcoin paper, =
that transactions with multiple inputs "necessarily reveal that their input=
s were owned by the same owner."[2] Breaking that common-input ownership as=
sumption requires contributions from multiple owners via interaction, namel=
y hosting a server endpoint secured by a certificate on the receiving side.=
 This problem has been singled out on this list as a barrier to greater pay=
join adoption.[3]

Instead of a peer-hosted endpoint, this scheme weilds a TURN[4] relay for c=
onnectivity and symmetric cryptography for security. Without a replacement =
for secured networking, the relay could steal funds. Aside from a pre-share=
d secret and relayed networking, the protocol takes the same form as the ex=
isting BIP 78 payjoin spec.


BASIC SCHEME


The recipient requests that the relay allocate them an endpoint at which th=
ey may be reached by UDP. Once allocated, they listen on it. They then gene=
rate a 256-bit key, psk. Out of band, they share a BIP 21[5] payjoin uri in=
cluding their unique relay allocation endpoint in the pj query parameter an=
d psk in a new psk query parameter.

The sender constructs their request containing an original PSBT as in BIP 7=
8. Instead of sending it over TLS or Tor, they follow noise framework NNpsk=
0[6] pattern. They encrypt the request using psk alongside an ephemeral sen=
der key and MAC. The resulting ciphertext ensures message secrecy and integ=
rity when relayed to the recipient by the pj endpoint.

The pay-to-endpoint protocol proceeds to produce a payjoin as in BIP 78 exc=
ept that messages are secured by the noise NNpsk0 pattern rather than TLS o=
r Tor.


IMPROVEMENTS


HTTP/3

TURN defaults to UDP. In order to adhere to the BIP 78 protocol HTTP messag=
ing, HTTP/3 should be used on top of TURN/UDP.
Offline Asynchronous Payjoins

It may be possible for a relay to hold a requeust for an offline payjoin pe=
er until that peer comes online. However, the BIP 78 spec recommends broadc=
asting request PSBTs in the case of an offline counterparty. Doing so expos=
es a na=C3=AFve, surveillance-vulnerable transaction which payjoin intends =
to avoid. More research needs to be done before such a protocol can be reco=
mmended.


Nostr

While a custom Nostr relay could in theory replace the TURN relay while sha=
ring shnorr crypto with bitcoin, it would require another protocol to synch=
ronize networking, since Nostr makes no assumptions about whether a peer is=
 online or not, and a careful cryptography audit to secure. TURN and Noise =
are already well understood, tested, and have production library support ac=
ross multiple popular languages and other bitcoin-related projects. Noise e=
ven has tooling for formal verification. Nostr relays may prove more likely=
 to allow public access and more robust if we figure out async payjoin, how=
ever.


NOTEWORTHY DETAILS


Attack vectors

Since TURN relays can be used for any kind of internet traffic they are vul=
nerable to the tragedy of the commons. Relay operators may impose authentic=
ation requirements for endpoint allocation provisions.

Since psk is a symmetric key, the first message containing the sender's ori=
ginal PSBT does not have forward secrecy.


Network Privacy

Peers will only see the IP address of the TURN relay but not their peer's. =
TURN relays may be made available via Tor hidden service in addition to IP =
to allow either of the peers to protect their IP with Tor without forcing t=
he other to use it too.


IMPLEMENTATION


I've published working proof of concept sender, receiver clients and relay =
code in rust[7]


ACKNOWLEDGEMENTS


Deepest gratitude to Ethan Heilman for sitting down with me to help get to =
the bottom of the requirements of this problem, to Ruben Somsen for this sl=
ick format, and to all those engaged in defending the right to privacy.


REFERENCES


[1]  BIP 78 A Simple Payjoin Proposal, Nicolas Doier:
https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki

[2]  Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto:
https://chaincase.app/bitcoin.pdf

[3]  [bitcoin-dev] PayJoin adoption, Craig Raw:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018358=
.html

[4]  RFC 5766: Traversal Using Relays around NAT (TURN):
https://www.rfc-editor.org/rfc/rfc5766

[5]  BIP 21 URI Scheme, Nils Schneider, Matt Corallo:
 https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki

[6]  Noise Explorer: NNpsk0:
https://noiseexplorer.com/patterns/NNpsk0

[7]  Serverless PayJoin PoC:
https://github.com/chaincase-app/payjoin/pull/21