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
|
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 <jgarzik@exmulti.com>) id 1QpDKO-0005VW-4U
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Aug 2011 05:52:12 +0000
X-ACL-Warn:
Received: from mail-iy0-f171.google.com ([209.85.210.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QpDKN-0003i8-Az
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Aug 2011 05:52:12 +0000
Received: by iyf13 with SMTP id 13so4123316iyf.30
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Aug 2011 22:52:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.166.74 with SMTP id n10mr1753074icy.67.1312523525572; Thu,
04 Aug 2011 22:52:05 -0700 (PDT)
Received: by 10.42.19.65 with HTTP; Thu, 4 Aug 2011 22:52:05 -0700 (PDT)
X-Originating-IP: [99.173.148.118]
In-Reply-To: <CAJNQ0stRrv4Yqf9ENszoXJE8+FpzwXZaGVDP=stZi27x4BRmmg@mail.gmail.com>
References: <CAJNQ0svWgFwZrra0gQFpxNLOPXk4RbKygeMUNPEA=k-Wqwa-ZA@mail.gmail.com>
<201108041038.47396.luke@dashjr.org>
<CABsx9T2tAeOp6RAb+Zb5zmzdSePZV90Uu=r4mzFc44d6ndbcnQ@mail.gmail.com>
<CAJNQ0stRrv4Yqf9ENszoXJE8+FpzwXZaGVDP=stZi27x4BRmmg@mail.gmail.com>
Date: Fri, 5 Aug 2011 01:52:05 -0400
Message-ID: <CA+8xBpd0ud0Jn7Xxfw3C-WCH12WuB7k_W5x00Mj2EidemGoYpQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: John Smith <witchspace81@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1QpDKN-0003i8-Az
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:52:12 -0000
On Fri, Aug 5, 2011 at 1:37 AM, John Smith <witchspace81@gmail.com> wrote:
> Well it's good that the bitcoin network is seeing some security testing.
Yep.
> 1) A DDoS possibility=A0 (if this is really the cause of the network
> connectivity problems)
Unfortunately the nodes accepting incoming connections are small
enough in number (7000?) that you can shut down a lot by attacking
those nodes.
This was part of the motivation of turning on upnp by default in the
GUI version, but maybe we need to go further than that...
> 3) The recipient re-broadcasts transactions (is Theymos right here?),
> allowing both the sender and recipient to be found
Yes, that is correct. Bitcoin resends wallet transactions with zero
confirmations, and both sent and received transactions fall within the
"wallet tx" superset.
TBH I had forgotten about the resend on the receiver side, though.
It, of course, makes plenty of sense in the context of importing
transactions from foreign sources, e.g. receiving transactions via a
USB flash drive.
> Drawok's suggestion about using UDP packets with spoofed sender addresses=
is
> interesting, as UDP has another advantage; you can open up an "inbound" U=
DP
> port on almost any NAT router without any UPNP magic: just send out an UD=
P
> 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).
Well, it -is- possible to implement TCP over UDP <grin> The TCP
connection sequence over UDP helps to work against spoofing, while UDP
helps to open an inbound UDP port as you describe.
Not that I'm endorsing a bitcoin-internal TCP stack... just sayin' :)
--=20
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
