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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <fahree@gmail.com>) id 1VCA4K-0003gJ-D2
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Aug 2013 15:11:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.44 as permitted sender)
client-ip=209.85.160.44; envelope-from=fahree@gmail.com;
helo=mail-pb0-f44.google.com;
Received: from mail-pb0-f44.google.com ([209.85.160.44])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VCA4J-0006JS-6N
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Aug 2013 15:11:32 +0000
Received: by mail-pb0-f44.google.com with SMTP id xa7so514592pbc.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 21 Aug 2013 08:11:25 -0700 (PDT)
X-Received: by 10.66.27.143 with SMTP id t15mr167432pag.171.1377097885248;
Wed, 21 Aug 2013 08:11:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.32.231 with HTTP; Wed, 21 Aug 2013 08:10:55 -0700 (PDT)
In-Reply-To: <201308211200.50200.luke@dashjr.org>
References: <CAN7nBXdW3H3fWHji0Hcem-eFnAxBYzmtrLBkYekVM=9DZBJVVw@mail.gmail.com>
<201308211200.50200.luke@dashjr.org>
From: =?ISO-8859-1?Q?Far=E9?= <fahree@gmail.com>
Date: Wed, 21 Aug 2013 11:10:55 -0400
Message-ID: <CAN7nBXcah3ffygZ=AKZmFadk6_RGQk1pVoYgN2M1Gmr5FUFUaw@mail.gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(fahree[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VCA4J-0006JS-6N
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Making bitcoin traceability harder
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 15:11:33 -0000
Dear Luke,
thanks for your prompt response.
On Wed, Aug 21, 2013 at 8:00 AM, Luke-Jr <luke@dashjr.org> wrote:
> Let me start out by noting that there are plenty of good ideas which coul=
d be
> implemented, but haven't been yet, and might take a long time to get to. =
There
> are only a couple handfuls of Bitcoin developers, and even fewer of us wh=
o are
> able to work full-time on Bitcoin development. Perhaps surprisingly, even=
this
> often isn't the bottleneck to new functionality: we have a terrible short=
age
> of testers, needed to make sure improvements don't break things in subtle
> ways. So, while your ideas are appreciated, please keep in mind that it m=
ay
> take time to add them, and you can help Bitcoin development much more by
> aiding in testing currently-written-but-untested features.
>
That's a useful reminder.
> With regard to your points made specifically, please note that addresses =
are
> intended to be single-use only. Thus, the "recurrent user of address A/B"=
are
> not using Bitcoin correctly already, which is why they are so easy to tra=
ce.
> As far as keeping change amounts as powers of two, while I would personal=
ly
> love to find a justification for power-of-two amounts, I don't see how th=
is
> would help privacy. I think it would actually hurt privacy, as change wou=
ld
> now be clearly identifiable. Furthermore, it would necessarily have to th=
row
> away excess as a transaction fee - some users would be very upset with th=
is.
>
Even when you don't reuse your address, by considering the amounts in
a transaction, it is often easy to identify what is the main amount
and what is the residual. e.g. "oh, he spent $1.99 worth of bitcoin
out of his big bitcoin address, so the $1.99 is being paid, and the
rest is still the same person", and so trace identities. By using
power-of-two buckets (based on the binary expansion of the amount), it
becomes harder to do amount analysis. Sometimes, buckets are joined or
split, but that still doesn't help much identify how several buckets
combine into one transaction. As for transaction fees =E2=80=94 indeed, the=
y
should probably be paid in separate small-bucket transactions. I don't
see any particular difficulty about it.
> As you suggest, it is of course already best practice for merchants (and
> individuals!) to use a unique payment address for every transaction. Gavi=
n's
> payment protocol work has been making some great progress toward improvin=
g
> usability for this. There is also a general consensus that Bitcoin-Qt's
> "Receive coins" tab could be significantly improved to discourage address
> reuse further. I don't believe it has been discussed to have merchants us=
e
> multiple addresses/coins for a single payment; that might be worth some
> further discussion here as a privacy extension, but I don't think many wo=
uld
> consider it an urgent issue (it may help, but probably not enough to make=
it
> worthwhile).
>
There is nothing urgent indeed. Nevertheless, I fear that the current
usage pattern is too easily traceable, and that tweaks such as the one
I'm proposing could make amount-based tracing much harder.
Thanks for your hard work!
=E2=80=94=E2=99=AF=C6=92 =E2=80=A2 Fran=C3=A7ois-Ren=C3=A9 =C3=90VB Rideau =
=E2=80=A2Reflection&Cybernethics=E2=80=A2 http://fare.tunes.org
He wa'n't no common dog, he wa'n't no mongrel; he was a composite.
A composite dog is a dog that is made up of all the valuable qualities
that's in the dog breed =E2=80=94 kind of a syndicate; and a mongrel is mad=
e up
of all riffraff that's left over. =E2=80=94 Mark Twain
|
