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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1VC76J-0006b0-CO
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Aug 2013 12:01:23 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VC76C-0003bN-Fi for bitcoin-development@lists.sourceforge.net;
Wed, 21 Aug 2013 12:01:23 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:222:4dff:fe50:4c49])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 2E11C27A2965;
Wed, 21 Aug 2013 12:01:03 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: =?utf-8?q?Far=C3=A9?= <fahree@gmail.com>
Date: Wed, 21 Aug 2013 12:00:48 +0000
User-Agent: KMail/1.13.7 (Linux/3.9.9-gentoo; KDE/4.10.5; x86_64; ; )
References: <CAN7nBXdW3H3fWHji0Hcem-eFnAxBYzmtrLBkYekVM=9DZBJVVw@mail.gmail.com>
In-Reply-To: <CAN7nBXdW3H3fWHji0Hcem-eFnAxBYzmtrLBkYekVM=9DZBJVVw@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201308211200.50200.luke@dashjr.org>
X-Spam-Score: -2.8 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-2.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1VC76C-0003bN-Fi
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 12:01:23 -0000
=46ar=C3=A9,
Let me start out by noting that there are plenty of good ideas which could =
be=20
implemented, but haven't been yet, and might take a long time to get to. Th=
ere=20
are only a couple handfuls of Bitcoin developers, and even fewer of us who =
are=20
able to work full-time on Bitcoin development. Perhaps surprisingly, even t=
his=20
often isn't the bottleneck to new functionality: we have a terrible shortag=
e=20
of testers, needed to make sure improvements don't break things in subtle=20
ways. So, while your ideas are appreciated, please keep in mind that it may=
=20
take time to add them, and you can help Bitcoin development much more by=20
aiding in testing currently-written-but-untested features.
With regard to your points made specifically, please note that addresses ar=
e=20
intended to be single-use only. Thus, the "recurrent user of address A/B" a=
re=20
not using Bitcoin correctly already, which is why they are so easy to trace=
=2E=20
As far as keeping change amounts as powers of two, while I would personally=
=20
love to find a justification for power-of-two amounts, I don't see how this=
=20
would help privacy. I think it would actually hurt privacy, as change would=
=20
now be clearly identifiable. Furthermore, it would necessarily have to thro=
w=20
away excess as a transaction fee - some users would be very upset with this.
As you suggest, it is of course already best practice for merchants (and=20
individuals!) to use a unique payment address for every transaction. Gavin'=
s=20
payment protocol work has been making some great progress toward improving=
=20
usability for this. There is also a general consensus that Bitcoin-Qt's=20
"Receive coins" tab could be significantly improved to discourage address=20
reuse further. I don't believe it has been discussed to have merchants use=
=20
multiple addresses/coins for a single payment; that might be worth some=20
further discussion here as a privacy extension, but I don't think many woul=
d=20
consider it an urgent issue (it may help, but probably not enough to make i=
t=20
worthwhile).
Luke
On Wednesday, August 21, 2013 3:39:12 AM Far=C3=A9 wrote:
> Dear bitcoin developers,
>=20
> trading arbitrary amounts of bitcoins makes it easier to trace who
> does what just by observing the amounts being traded, and where the
> residual money ends up: e.g. you can identify that obviously, the
> recurrent user of address A sent 2.5 bitcoins to the recurrent user of
> address B, keeping the rest of his money in A. If instead bitcoin
> users practice the discipline, enforced by the client software by
> default, of only keeping a power-of-two amount of satoshis in use-once
> wallets except where public donation addresses are meant, then tracing
> suddenly becomes much harder.
>=20
> Whether this particular discipline is the best to implement or not,
> shouldn't bitcoin clients enforce SOME discipline that makes tracing
> harder? After all we know that uniformed goons are eager to watch
> who's trading with whom and to crack down on users. We shouldn't be
> making it easy for them, though this will mean slightly higher
> transaction cost. Merchants would then generate not one but a series
> of new addresses at each transaction, and the customer would send
> appropriately sized buckets of satoshis to each of the addresses.
> There should just be a standard way to specify an amount and a list of
> addresses as a target for payment, that merchants can communicate to
> customers (though that might require e.g. higher resolution QR codes).
>=20
> Has this idea already been considered before? Accepted or rejected?
>=20
> =E2=80=94=E2=99=AF=C6=92 =E2=80=A2 Fran=C3=A7ois-Ren=C3=A9 =C3=90VB Ridea=
u =E2=80=A2Reflection&Cybernethics=E2=80=A2
> http://fare.tunes.org Of course, Third World leaders love you. By
> ascribing third world ills to First World sins, you absolve them of blame
> for their countries' failure to advance. =E2=80=94 John McCarthy
>=20
> -------------------------------------------------------------------------=
=2D-
> --- Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=3D48897511&iu=3D/4140/ostg.=
clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
