From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A3A70C002D for ; 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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