summaryrefslogtreecommitdiff
path: root/02/26771bfed3ce4063d2bea633f47d0c2afd6101
blob: 427c7cf2f2d7c198b0b808aa2ddd9f9b0ed8317b (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1XuE8f-00040Q-Vd
	for bitcoin-development@lists.sourceforge.net;
	Fri, 28 Nov 2014 05:30:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.171 as permitted sender)
	client-ip=209.85.213.171; envelope-from=gmaxwell@gmail.com;
	helo=mail-ig0-f171.google.com; 
Received: from mail-ig0-f171.google.com ([209.85.213.171])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XuE8c-0001US-7G
	for bitcoin-development@lists.sourceforge.net;
	Fri, 28 Nov 2014 05:30:41 +0000
Received: by mail-ig0-f171.google.com with SMTP id z20so5370400igj.10
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 27 Nov 2014 21:30:33 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.66.179 with SMTP id g19mr31189623igt.8.1417152632957;
	Thu, 27 Nov 2014 21:30:32 -0800 (PST)
Received: by 10.107.18.65 with HTTP; Thu, 27 Nov 2014 21:30:32 -0800 (PST)
In-Reply-To: <CABssiCpUE=3GhC+Scd3htzVb9+gmLeZ0mEO5LY-zxywvguZ--w@mail.gmail.com>
References: <CABssiCpUE=3GhC+Scd3htzVb9+gmLeZ0mEO5LY-zxywvguZ--w@mail.gmail.com>
Date: Fri, 28 Nov 2014 05:30:32 +0000
Message-ID: <CAAS2fgRPZ5yrHYrdG8fEZQi92J-DVY_fZNFc8wnt81Pvx_mLNQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mistr Bigs <misterbg6@gmail.com>
Content-Type: text/plain; charset=UTF-8
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
	(gmaxwell[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: 1XuE8c-0001US-7G
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P
 network paper
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: Fri, 28 Nov 2014 05:30:42 -0000

On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs <misterbg6@gmail.com> wrote:
> That's what I was trying to say... The researchers are deanonymizing
> transactions from non-Tor connected hosts. So why are we talking about Tor
> limitations in response to this? Shouldn't we be discussing how to address
> the issues in Bitcoin proper?

Because if the user does not use tor or an analogous infrastructure
(e.g. something else reimplementing tor's functionality) the user can
be deanonymized in many different ways.

At the end of the day, if I'm listening widely to the network, and
your host is regularly the first to hand me your transactions then I
can draw reasonably reliable conclusions... and this is true even if
there is a complete absence of identifiable characteristics otherwise.

And, on the flip side if the host is persistently behind tor, even
with some watermarkable behaviour, their privacy is protected.  So
making sure that hosts can continually use tor (or similar systems)
should be the higher priority.  (And, of course, not reimplementing
tor  leverages the millions of dollars of investment and dozens of
subject matter experts working on that system).