From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 31F79C0032 for ; Sun, 20 Aug 2023 17:13:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 04A4060B2D for ; Sun, 20 Aug 2023 17:13:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 04A4060B2D Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=rfIXyZp9 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfBm-MmECgDO for ; Sun, 20 Aug 2023 17:13:53 +0000 (UTC) Received: from mail-4327.protonmail.ch (mail-4327.protonmail.ch [185.70.43.27]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1325960AFD for ; Sun, 20 Aug 2023 17:13:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1325960AFD Date: Sun, 20 Aug 2023 17:13:33 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.b="rfIXyZp9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1692551619; x=1692810819; bh=dECWS8o/iA/Ir1kxo8qH7pABu0oPc2+DE4wFGJB3N+8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=rfIXyZp9+NIiJSMa6eLbOcsPFonFwcn07JkwCvU+/G6iCPADg/V8pIUVBeU1Uit1F VLLot3JkjgcJxbjSpyrl+gJjRUMG65PrzaHAU1aTxaxNhkvD2CSttYOO0xvUfhnpYF WpqoRJjxsrCrKDHnucZNe42dr1MvszllNquQJ4lZ/sWNU6Kb6fw4fBcYApOjkcsO3M h8WHBgnrzglKDVMii/g2pidHDlAjGUBRupp66MFt5e1YCywloN10J8ARL2bPWLQZcF vhkA+G4qkgegxNG+K3MxmsSBmDkDsON9fffizQRvjbJ3bniyICEqxyL2iHpoTpWPOl TEJtDtADwcSjw== To: Dan Gould From: alicexbt Message-ID: <8qSa5NNuqF64Yg-R-OvO34IYBI0efPOUYYGrFBwvhsDuRMdQzcA6joTi0BNdBkoGgZQgBut257mfwX1e-bDdExlmcxdtRrSjCtWYPBlne6M=@protonmail.com> In-Reply-To: <3C0A6E4C-444E-4E75-829C-1A21D8EE40E0@ngould.dev> References: <3C0A6E4C-444E-4E75-829C-1A21D8EE40E0@ngould.dev> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Aug 2023 00:12:10 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [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, 20 Aug 2023 17:13:55 -0000 Hi Dan, May be too late to reply. Sorry. Based on our last communication, I wanted to share these points after readi= ng 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 j= ust metadata leak which should be okay if a new npub is used every time use= rs 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 us= ed. 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 wrote: > Hi all, >=20 > 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. >=20 > I think this work raises a greater problem which is that payjoin assumes = synchronous communication while it=E2=80=99s an asynchronous world. >=20 > 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 >=20 > Best regards, > Dan >=20 >=20 >=20 > Serverless Payjoin >=20 >=20 > Receive surveillance-busting bitcoin transfers without hosting a secure e= ndpoint >=20 >=20 >=20 > OVERVIEW >=20 >=20 > Payjoin[1] solves the sole privacy problem left open in the bitcoin paper= , that transactions with multiple inputs "necessarily reveal that their inp= uts were owned by the same owner."[2] Breaking that common-input ownership = assumption requires contributions from multiple owners via interaction, nam= ely hosting a server endpoint secured by a certificate on the receiving sid= e. This problem has been singled out on this list as a barrier to greater p= ayjoin adoption.[3] >=20 > Instead of a peer-hosted endpoint, this scheme weilds a TURN[4] relay for= connectivity and symmetric cryptography for security. Without a replacemen= t for secured networking, the relay could steal funds. Aside from a pre-sha= red secret and relayed networking, the protocol takes the same form as the = existing BIP 78 payjoin spec. >=20 >=20 >=20 > BASIC SCHEME >=20 >=20 > 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 ge= nerate 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. >=20 > 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 NNp= sk0[6] pattern. They encrypt the request using psk alongside an ephemeral s= ender key and MAC. The resulting ciphertext ensures message secrecy and int= egrity when relayed to the recipient by the pj endpoint. >=20 > The pay-to-endpoint protocol proceeds to produce a payjoin as in BIP 78 e= xcept that messages are secured by the noise NNpsk0 pattern rather than TLS= or Tor. >=20 >=20 >=20 > IMPROVEMENTS >=20 >=20 > HTTP/3 >=20 > TURN defaults to UDP. In order to adhere to the BIP 78 protocol HTTP mess= aging, HTTP/3 should be used on top of TURN/UDP. > Offline Asynchronous Payjoins >=20 > 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 broa= dcasting request PSBTs in the case of an offline counterparty. Doing so exp= oses a na=C3=AFve, surveillance-vulnerable transaction which payjoin intend= s to avoid. More research needs to be done before such a protocol can be re= commended. >=20 >=20 > Nostr >=20 > While a custom Nostr relay could in theory replace the TURN relay while s= haring shnorr crypto with bitcoin, it would require another protocol to syn= chronize networking, since Nostr makes no assumptions about whether a peer = is online or not, and a careful cryptography audit to secure. TURN and Nois= e 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 like= ly to allow public access and more robust if we figure out async payjoin, h= owever. >=20 >=20 >=20 > NOTEWORTHY DETAILS >=20 >=20 > Attack vectors >=20 > Since TURN relays can be used for any kind of internet traffic they are v= ulnerable to the tragedy of the commons. Relay operators may impose authent= ication requirements for endpoint allocation provisions. >=20 > Since psk is a symmetric key, the first message containing the sender's o= riginal PSBT does not have forward secrecy. >=20 >=20 > Network Privacy >=20 > 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 I= P to allow either of the peers to protect their IP with Tor without forcing= the other to use it too. >=20 >=20 >=20 > IMPLEMENTATION >=20 >=20 > I've published working proof of concept sender, receiver clients and rela= y code in rust[7] >=20 >=20 >=20 > ACKNOWLEDGEMENTS >=20 >=20 > Deepest gratitude to Ethan Heilman for sitting down with me to help get t= o 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. >=20 >=20 >=20 > REFERENCES >=20 >=20 > [1] BIP 78 A Simple Payjoin Proposal, Nicolas Doier: > https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki >=20 > [2] Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto: > https://chaincase.app/bitcoin.pdf >=20 > [3] [bitcoin-dev] PayJoin adoption, Craig Raw: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/0183= 58.html >=20 > [4] RFC 5766: Traversal Using Relays around NAT (TURN): > https://www.rfc-editor.org/rfc/rfc5766 >=20 > [5] BIP 21 URI Scheme, Nils Schneider, Matt Corallo: > https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki >=20 > [6] Noise Explorer: NNpsk0: > https://noiseexplorer.com/patterns/NNpsk0 >=20 > [7] Serverless PayJoin PoC: > https://github.com/chaincase-app/payjoin/pull/21 >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev