Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E9C33C016F for ; Wed, 10 Jun 2020 06:29:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id D520922849 for ; Wed, 10 Jun 2020 06:29:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhT4Oj0y2+W3 for ; Wed, 10 Jun 2020 06:29:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by silver.osuosl.org (Postfix) with ESMTPS id B2F16221D9 for ; Wed, 10 Jun 2020 06:29:21 +0000 (UTC) Date: Wed, 10 Jun 2020 06:29:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591770559; bh=GsheVI4ttknrh3GDscam63y7yp+HVub9C6p3O0xdJXg=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=eXws3ImoXsjSaXESfH5CYcvQZ2gdgobE9eD11ZX3Ob3/klWFDZjRUefjNKDxoshJa /Tl2e8koslsBdGX9DzdDhvwXyH8MPgtGd3qAic6VMUs32sHxhOXurECOglma7YRw/i 6ZZpZ65jNTnBQi0uEeixYmFUIQ4zh+sbOtkKcjNY= To: "Mr. Lee Chiffre" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <7c0dc46538f96032596163c4a9f03dc2.squirrel@giyzk7o6dcunb2ry.onion> References: <7c0dc46538f96032596163c4a9f03dc2.squirrel@giyzk7o6dcunb2ry.onion> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Question about PayJoin effectiveness 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: Wed, 10 Jun 2020 06:29:24 -0000 Good morning Mr. Lee, > I am trying to learn about payjoin. I have a couple concerns on its > effectiveness. Are my concerns valid or am I missing something? > > concern 1 > If it is known to be a payjoin transaction anyone could determine the > sender the recipient and amount right? > > Lets assume that everyone has a single utxo because payjoin becomes commo= n > use and payjoin consolidates utxos through "snowballing". If Alice has a > UTXO of 0.05 btc and Bob has a UTXO of 1.15 btc. Bob can be assumed to > have more balance because he is a merchant and his customers payjoin him > payments alot. > > If Alice and Bob do a payjoin with Alice paying 0.01 btc to Bob, it would > probably look like this right? > > 0.05---> |____---->1.16 > 1.15---> | ---->0.04 There are multiple interpretations: * The 0.05 owner is paying the 1.15 owner 0.01 BTC. * The 1.15 owner is paying the 0.05 owner 1.11 BTC. * The 0.05 + 1.15 owner is paying an independent user 1.16 BTC using a non-= PayJoin transaction (because for example the payee currently has no coins, = i.e. a new user). It is this fact of multiple interpretations that is what PayJoin buys you i= n practice. You could argue that paying 0.01 is more likely than paying 1.11 or 1.16, b= ut that still does not give you 100% assurance --- the creators of the tran= saction are still getting the `100% - probability_of_paying_0.01` benefit, = and reducing UTXO set size as well. Your assertion that this is "very obvious" only exists because you already = know that Alice is paying 0.01 to Bob, but that is in fact the very thing t= hat is being obscured here. > > It is very obvious here the amount sent and the sender. Even if Alice did > combine another input it would still be very obvious. In this case Alice > has another utxo with 0.4 BTC > > 0.40---> | > 0.05---> |____---->1.16 > 1.15---> | ---->0.44 This can be interpreted as well multiple ways: * 0.05 + 1.15 is the same owner who wants to merge coins, and is paying the= 0.40 owner 0.04 BTC. * 0.40 + 1.15 is the same owner who wants to merge coins, and is paying the= 0.05 owner 0.39 BTC. * 0.40 + 0.05 is the same owner who wants to merge coins, and is paying the= 1.15 owner 0.01 BTC. You should probably be shuffling the inputs and outputs, or using BIP39 con= sistently, so that inputs and outputs do not correlate (i.e. do not necessa= rily group together all of Alice inputs). > > This is still obvious that Alice paid Bob 0.01 BTC isn't it? > > concern 2 > If there is just one consolidated utxo after each payjoin, would it be > easy to break the privacy of transaction chains? > > Alice---payjoin--->Bob > Clark---payjoin--->Bob > > or > > Alice---payjoin--->Bob---payjoin--->Clark > > For exmaple, lets say that Alice payjoins to Bob. Then later on Clark > payjoins with Bob. Based on the payjoin between Clark and Bob, Clark now > knows what UTXO was actually Bob's. And can then know which one was > actually Alices. By transacting a payjoin with someone, they could decloa= k > the payjoins before them right? If so, how far back the chain can they go= ? > > The issue is not that someone knows the utxos of themselves and the entit= y > they payjoined with. The issue is that someone can figure out the payjoin= s > of others before them with the same entity. If Clark can hack Alice (even just read-only access to Alice logs), they ca= n go by one more transaction. If Clark cannot hack Alice, then that is the sole extent Clark knows: Clark= know that Bob transacted with somebody for a resulting N BTC (which is rel= atively uninteresting, obviously somebody who uses BTC is going to be trans= acting with random BTC users in BTC), without being sure that Bob was the p= ayer or the payee in that situation. Regards, ZmnSCPxj