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
|
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 <fahree@gmail.com>) id 1VBzGw-0000o7-UT
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Aug 2013 03:39:50 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.170 as permitted sender)
client-ip=209.85.192.170; envelope-from=fahree@gmail.com;
helo=mail-pd0-f170.google.com;
Received: from mail-pd0-f170.google.com ([209.85.192.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VBzGu-0002R2-DV
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Aug 2013 03:39:50 +0000
Received: by mail-pd0-f170.google.com with SMTP id x10so1278651pdj.15
for <bitcoin-development@lists.sourceforge.net>;
Tue, 20 Aug 2013 20:39:42 -0700 (PDT)
X-Received: by 10.68.48.166 with SMTP id m6mr5388574pbn.105.1377056382396;
Tue, 20 Aug 2013 20:39:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.32.231 with HTTP; Tue, 20 Aug 2013 20:39:12 -0700 (PDT)
From: =?ISO-8859-1?Q?Far=E9?= <fahree@gmail.com>
Date: Tue, 20 Aug 2013 23:39:12 -0400
Message-ID: <CAN7nBXdW3H3fWHji0Hcem-eFnAxBYzmtrLBkYekVM=9DZBJVVw@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
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.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.170 listed in list.dnswl.org]
-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: 1VBzGu-0002R2-DV
Subject: [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 03:39:51 -0000
Dear bitcoin developers,
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.
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).
Has this idea already been considered before? Accepted or rejected?
=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
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
|
