1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id E9C33C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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" <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
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: 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
|
