[bitcoin-dev] Serverless Payjoin

[bitcoin-dev] Serverless Payjoin

[Dan Gould]

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

Re: [bitcoin-dev] Serverless Payjoin

[alicexbt]

Hi Dan,

May be too late to reply. Sorry.

Based on our last communication, I wanted to share these points after reading https://payjoin.substack.com/p/serverless-payjoin-gets-its-wings so that other can also evaluate them:

1) I don't think NIP 4 has any security issues. Maybe privacy issues. Its just metadata leak which should be okay if a new npub is used every time users do payjoin. Message itself will remain secret because it's encrypted.
2) Backwards compatibility due to npub, relay etc. shared in payjoin URI as implemented by Kukks. Not sure how to fix this.
3) Relays have no incentive to anything malicious if multiple relays are used. Although I am still not clear what malicious activity can they do with encrypted messages.
4) IP address is an issues with lot of projects and this can be managed by users or wallet implementation with the use of RiseupVPN, Tor, i2p etc.
5) Random padding suggested by a few senior devs makes sense.

/dev/fd0

floppy disk guy

------- Original Message -------
On Monday, January 23rd, 2023 at 2:20 AM, Dan Gould via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> 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
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev