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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1RdFWq-0006Kn-OQ
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Dec 2011 06:19:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=elombrozo@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RdFWp-0005J1-Nt
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Dec 2011 06:19:52 +0000
Received: by vbbfc21 with SMTP id fc21so7742214vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 20 Dec 2011 22:19:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.94.97 with SMTP id db1mr3175669vdb.16.1324448386296; Tue,
20 Dec 2011 22:19:46 -0800 (PST)
Received: by 10.52.162.6 with HTTP; Tue, 20 Dec 2011 22:19:46 -0800 (PST)
Date: Tue, 20 Dec 2011 22:19:46 -0800
Message-ID: <CABr1YTcq+q6jUSqPqNAqYYQHZO-FZx9ffCNNu_2nV8rcvzd9Uw@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
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
(elombrozo[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: 1RdFWp-0005J1-Nt
Subject: Re: [Bitcoin-development] Protocol extensions
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 Dec 2011 06:19:52 -0000
There are other issues besides IP address anonymization that would
need to be addressed. I'm sure at least a good number of you have read
http://arxiv.org/abs/1107.4524 and have seen Dan Kaminsky's
slideshows.
i.e. all fund aggregations (transactions with multiple inputs using
different public keys) make it easy to associate all the public keys
to a single entity. Large movements of bitcoin to addresses that
haven't been seen before are often interesting events. Then you can
correlate transactions with trades on exchanges or with other data
sources for time and amount.
However, going back to what had been said earlier, the bitcoin
protocol itself is not really designed to address these issues. It is
designed with the goal of rapidly propagating transactions over a
network and getting a bunch of peers to be able to independently
verify that they occurred in a particular order and that the
signatures are valid.
The subject of how to anonymize cryptocurrencies is a separate one,
IMHO...and one which needs to address not only how to hide the
identity of those who relay transactions but also how to organize and
manipulate wallets as to thwart attempts at block chain analysis. And
these topics, although interesting in and of themselves, was not what
this thread was intended to address. This thread was intended to
address the issue of extending the protocol to allow for independently
running thin or specialized services that can all interface via the
bitcoin protocol without requiring one to step outside the protocol
with special gateway access.
|
