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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1QpKJG-0000jP-1u
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Aug 2011 13:19:30 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.175 as permitted sender)
client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com;
helo=mail-yx0-f175.google.com;
Received: from mail-yx0-f175.google.com ([209.85.213.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1QpKJF-0007bb-Eu
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Aug 2011 13:19:30 +0000
Received: by yxi19 with SMTP id 19so2180827yxi.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 05 Aug 2011 06:19:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.8.10 with SMTP id 10mr3068686ybh.60.1312550364053; Fri, 05
Aug 2011 06:19:24 -0700 (PDT)
Received: by 10.150.52.5 with HTTP; Fri, 5 Aug 2011 06:19:23 -0700 (PDT)
In-Reply-To: <201108051407.06216.andyparkins@gmail.com>
References: <CAJNQ0svWgFwZrra0gQFpxNLOPXk4RbKygeMUNPEA=k-Wqwa-ZA@mail.gmail.com>
<201108041038.47396.luke@dashjr.org>
<CABsx9T2tAeOp6RAb+Zb5zmzdSePZV90Uu=r4mzFc44d6ndbcnQ@mail.gmail.com>
<201108051407.06216.andyparkins@gmail.com>
Date: Fri, 5 Aug 2011 13:19:23 +0000
Message-ID: <CAJNQ0stJeFx0X+vHZfx-3SHt3=0JAho_kqDU44mZM613YuUaSA@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: multipart/alternative; boundary=000e0cd2537c33017a04a9c1f2fe
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: 1QpKJF-0007bb-Eu
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 13:19:30 -0000
--000e0cd2537c33017a04a9c1f2fe
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 5, 2011 at 1:07 PM, Andy Parkins <andyparkins@gmail.com> wrote:
> On 2011 August 05 Friday, Gavin Andresen wrote:
>
> Transaction forwarding could be randomised slightly, by randomising the
> outgoing relay order; and adding a random delay between each forward. Even
> the massively connected monitor can't represent _all_ the connections on
> every
> real node, so it would have no way of knowing whether it got any
> transaction
> from the originator or because it got a fast path through the first N nodes
> to
> receive it.
>
Right, while it doesn't warrant completely changing the transport protocol
to UDP or implementing onion routing, I'm all for simple timing and order
randomization changes if they can make attacks like this less effective.
JS
--000e0cd2537c33017a04a9c1f2fe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 1:07 PM, Andy Par=
kins <span dir=3D"ltr"><<a href=3D"mailto:andyparkins@gmail.com" target=
=3D"_blank">andyparkins@gmail.com</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<div>On 2011 August 05 Friday, Gavin Andresen wrote:<br>
<br>
</div>Transaction forwarding could be randomised slightly, by randomising t=
he<br>
outgoing relay order; and adding a random delay between each forward. =A0Ev=
en<br>
the massively connected monitor can't represent _all_ the connections o=
n every<br>
real node, so it would have no way of knowing whether it got any transactio=
n<br>
from the originator or because it got a fast path through the first N nodes=
to<br>
receive it.<br></blockquote><div><br>Right, while it doesn't warrant co=
mpletely changing the transport protocol to UDP or implementing onion routi=
ng,=A0 I'm all for simple timing and order randomization changes if the=
y can make attacks like this less effective.<br>
<br>JS<br><br></div></div>
--000e0cd2537c33017a04a9c1f2fe--
|
