[bitcoin-dev] Serverless Payjoin

* [bitcoin-dev] Serverless Payjoin
@ 2023-01-22 20:50 Dan Gould
  2023-08-20 17:13 ` alicexbt
  0 siblings, 1 reply; 2+ messages in thread
From: Dan Gould @ 2023-01-22 20:50 UTC (permalink / raw)
  To: bitcoin-dev

Hi all,

I'm publishing a payjoin upgrade in response to a request from this list. The payjoin receiver no longer has to run a public server. They lean on a relay 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 synchronous communication while it’s an asynchronous world.

I added the full write-up in plain text below, though I recommend reading the 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 endpoint

OVERVIEW

Payjoin[1] solves the sole privacy problem left open in the bitcoin paper, that transactions with multiple inputs "necessarily reveal that their inputs were owned by the same owner."[2] Breaking that common-input ownership assumption requires contributions from multiple owners via interaction, namely 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 payjoin adoption.[3]

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

BASIC SCHEME

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

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

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

IMPROVEMENTS

HTTP/3

TURN defaults to UDP. In order to adhere to the BIP 78 protocol HTTP messaging, 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 peer until that peer comes online. However, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty. Doing so exposes a naïve, surveillance-vulnerable transaction which payjoin intends to avoid. More research needs to be done before such a protocol can be recommended.

Nostr

While a custom Nostr relay could in theory replace the TURN relay while sharing shnorr crypto with bitcoin, it would require another protocol to synchronize 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 across multiple popular languages and other bitcoin-related projects. Noise even has tooling for formal verification. Nostr relays may prove more likely to allow public access and more robust if we figure out async payjoin, however.

NOTEWORTHY DETAILS

Attack vectors

Since TURN relays can be used for any kind of internet traffic they are vulnerable to the tragedy of the commons. Relay operators may impose authentication requirements for endpoint allocation provisions.

Since psk is a symmetric key, the first message containing the sender's original 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 the 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 slick 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

^ permalink raw reply	[flat|nested] 2+ messages in thread