path: root/45/c86336f32d26c682128a4178b4701265a83db2

Return-Path: <alicexbt@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 31F79C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <d@ngould.dev>
From: alicexbt <alicexbt@protonmail.com>
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 <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, 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 <bitcoi=
n-dev@lists.linuxfoundation.org> 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