path: root/5f/2d5bd3bbcfb656b7bf8cde21336b39e05df0f9

Return-Path: <d@ngould.dev>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A3A70C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 22 Jan 2023 20:57:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 6A54941517
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 22 Jan 2023 20:57:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6A54941517
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev
 header.a=rsa-sha256 header.s=protonmail header.b=Y8PNZ68e
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id aplIvHoho6pR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 22 Jan 2023 20:57:11 +0000 (UTC)
X-Greylist: delayed 00:06:07 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DA4E341511
Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch
 [185.70.41.104])
 by smtp4.osuosl.org (Postfix) with ESMTPS id DA4E341511
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 22 Jan 2023 20:57:10 +0000 (UTC)
Date: Sun, 22 Jan 2023 20:50:44 +0000
Authentication-Results: mail-41104.protonmail.ch;
 dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev
 header.b="Y8PNZ68e"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ngould.dev;
 s=protonmail; t=1674420649; x=1674679849;
 bh=/g8mkYEjWUcILGsaBX/K0iXl7p3rFvis9XQT096HG4M=;
 h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
 b=Y8PNZ68esdrtUUgyhJ+gVFipSd3i6x0W38tdEFcjIl/f1oc3gOID4m2p7fLbBxCSk
 mgDJJYdQNsrudrCnq52cRueL4Y3uefRwV/RB1XY+IWMb2T1pxaLvaK4e2gVBAWbd49
 3X6My/NDD10PKpPHPQvBD/3uQmemcKYJYcxRLQbY=
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
X-Mailman-Approved-At: Sun, 22 Jan 2023 21:01:53 +0000
Subject: [bitcoin-dev] 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: Sun, 22 Jan 2023 20:57:12 -0000


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