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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1QpD6T-0000hY-4t
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Aug 2011 05:37:49 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.47 as permitted sender)
client-ip=74.125.83.47; envelope-from=witchspace81@gmail.com;
helo=mail-gw0-f47.google.com;
Received: from mail-gw0-f47.google.com ([74.125.83.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1QpD6S-000356-Gf
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Aug 2011 05:37:49 +0000
Received: by gwb11 with SMTP id 11so591469gwb.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Aug 2011 22:37:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.8.10 with SMTP id 10mr2681080ybh.60.1312522662987; Thu, 04
Aug 2011 22:37:42 -0700 (PDT)
Received: by 10.150.52.5 with HTTP; Thu, 4 Aug 2011 22:37:42 -0700 (PDT)
In-Reply-To: <CABsx9T2tAeOp6RAb+Zb5zmzdSePZV90Uu=r4mzFc44d6ndbcnQ@mail.gmail.com>
References: <CAJNQ0svWgFwZrra0gQFpxNLOPXk4RbKygeMUNPEA=k-Wqwa-ZA@mail.gmail.com>
<201108041038.47396.luke@dashjr.org>
<CABsx9T2tAeOp6RAb+Zb5zmzdSePZV90Uu=r4mzFc44d6ndbcnQ@mail.gmail.com>
Date: Fri, 5 Aug 2011 05:37:42 +0000
Message-ID: <CAJNQ0stRrv4Yqf9ENszoXJE8+FpzwXZaGVDP=stZi27x4BRmmg@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=000e0cd2537c164a1404a9bb7f94
X-Spam-Score: -0.5 (/)
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
(witchspace81[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (witchspace81[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1QpD6S-000356-Gf
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
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, 05 Aug 2011 05:37:49 -0000
--000e0cd2537c164a1404a9bb7f94
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 5, 2011 at 1:16 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
>
> ... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin
> address. And might go partway to explaining why we're having trouble with
> network connectivity...
>
Well it's good that the bitcoin network is seeing some security testing.
So I understand that we have a combination of problems at the moment:
1) A DDoS possibility (if this is really the cause of the network
connectivity problems)
2) An attacker can figure out which node first broadcasted a transaction, by
connecting to the entire network or having everyone connect to his node(s)
3) The recipient re-broadcasts transactions (is Theymos right here?),
allowing both the sender and recipient to be found
Drawok's suggestion about using UDP packets with spoofed sender addresses is
interesting, as UDP has another advantage; you can open up an "inbound" UDP
port on almost any NAT router without any UPNP magic: just send out an UDP
packet, the router will wait a certain time for answers (on a mapped port
number) and relay these back.
It also has some potential issues; the client needs special privileges to
spoof sender addresses, and some ISPs might filter out packets with
non-matching sender addriess (unsure how common this is).
JS
--000e0cd2537c164a1404a9bb7f94
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 1:16 AM, Gavin Andres=
en <span dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com">gavinan=
dresen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div><font face=3D"verdana, sans-serif"><span style=3D"line-height:16px=
">... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin a=
ddress. =A0And might go partway to explaining why we're having trouble =
with network connectivity...</span></font></div>
</blockquote><div><br>Well it's good that the bitcoin network is seeing=
some security testing.<br><br>So I understand that we have a combination o=
f problems at the moment:<br><br>1) A DDoS possibility=A0 (if this is reall=
y the cause of the network connectivity problems)<br>
<br>2) An attacker can figure out which node first broadcasted a transactio=
n, by connecting to the entire network or having everyone connect to his no=
de(s)<br><br>3) The recipient re-broadcasts transactions (is Theymos right =
here?), allowing both the sender and recipient to be found<br>
<br>Drawok's suggestion about using UDP packets with spoofed sender add=
resses is interesting, as UDP has another advantage; you can open up an &qu=
ot;inbound" UDP port on almost any NAT router without any UPNP magic: =
just send out an UDP packet, the router will wait a certain time for answer=
s (on a mapped port number) and relay these back. <br>
<br>It also has some potential issues; the client needs special privileges =
to spoof sender addresses, and some ISPs might filter out packets with non-=
matching sender addriess (unsure how common this is).<br><br>JS<br><br>
</div></div>
--000e0cd2537c164a1404a9bb7f94--
|
