Date: Wed, 10 Jun 2020 06:29:08 +0000
To: "Mr. Lee Chiffre" <lee.chiffre@secmail.pro>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <sjC0RVZr0Uyg5QKjgmAQfNibCUtaG-r_XEO8xDgPd7GIjLKSEybd47utANFWA53yySigMzqfiotpbCdFy-M5NcxJN1J6cCQO1r3sR1-eVks=@protonmail.com>
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
Precedence: list


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