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
133
134
135
136
137
138
139
140
141
142
|
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 <pete@petertodd.org>) id 1VBEMt-0003BR-Nc
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Aug 2013 01:34:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.77 as permitted sender)
client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
helo=outmail149077.authsmtp.com;
Received: from outmail149077.authsmtp.com ([62.13.149.77])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VBEMs-0002fg-G7 for bitcoin-development@lists.sourceforge.net;
Mon, 19 Aug 2013 01:34:51 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r7J1YhQh082159; Mon, 19 Aug 2013 02:34:43 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r7J1YcTL059828
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 19 Aug 2013 02:34:40 +0100 (BST)
Date: Sun, 18 Aug 2013 21:34:37 -0400
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20130819013437.GA21524@savin>
References: <20130819001357.GA4281@savin>
<CABsx9T3MFqmLchc1Uu20BhiVKsYWFtt0eneVSey846y2hdQ7Rg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw"
Content-Disposition: inline
In-Reply-To: <CABsx9T3MFqmLchc1Uu20BhiVKsYWFtt0eneVSey846y2hdQ7Rg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 852e41b1-086f-11e3-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwsUGUATAgsB AmUbW1ZeU1l7XWE7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqBmYA b016Lhl3fg1EcDBx ZU5nXz5TWUYvcUcv
Q1NUHWtQeGZhPWMC AkULch5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4hGjk7 QlgDGn0mAVEMTCZ7
IhIoJ1UAHVgcNEgp KjMA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1VBEMs-0002fg-G7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom io attack effectiveness
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: Mon, 19 Aug 2013 01:34:51 -0000
--GvXjxJ+pjyke8COw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 19, 2013 at 10:59:18AM +1000, Gavin Andresen wrote:
> Peter said:
> "In any case given that SPV peers don't contribute back to the network
> they should obviously be heavily deprioritized and served only with
> whatever resources a node has spare."
>=20
> This seems very much like a "cut off your nose to spite your face" soluti=
on.
>=20
> SPV peers are INCREDIBLY IMPORTANT to the growth of Bitcoin; much more
> important than nodes that have the bandwidth and disk I/O capability of
> being a full node. Bitcoin will be just fine if there are never more than
> 10,000 big, beefy, full nodes forming the backbone of the network, but wi=
ll
> be NOTHING if we don't support tens of millions of lightweight SPV device=
s.
>=20
> Ok, that's an exaggeration, Bitcoin would be just fine in an Electrum mod=
el
> where tens of millions of lightweight devices rely 100% on a full node to
> operate. But I would prefer the more decentralized, less-trust-required S=
PV
> model.
Don't read too much into what I said; under normal circumstances when a
Bitcoin node isn't being attacked, there will be plenty of spare
capacity for SPV nodes. All I'm suggesting is that we make sure serving
those nodes doesn't come at the expense of maintaining consensus -
mainly distributing new blocks around the network so the blockchain
keeps moving forward. (something many SPV peers can help with anyway)
I'd much rather my Android wallet take a long time to sync up, than
blocks get re-organized because miners found themselves separated from
one another, let along someone clever using that to do double-spend
attacks during those re-orgs. After all, I can always find a private
node to connect to that won't be overloaded because it doesn't accept
connections from anonymous users. It's also easy to just use really
basic measures to limit abuse, like "sign up with your bitcointalk"
account, or "pay 10 cents for an account to discourage spammers"
Anyway all things less likely to be needed if attackers know all they
are going to manage to do is inconvenience people temporarily because
the network itself will keep running.
--=20
'peter'[:-1]@petertodd.org
--GvXjxJ+pjyke8COw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSEXYtAAoJECSBQD2l8JH7lzcIALAY0o1yZ4JZcj/JmbaODrsW
96b4NGYv/4cMltqhPijuKn23MIvuG7JjaNu9f4J6Bmt5jOSnIyVPz5XZzsjWD3EW
IFFGZ3GYg5C5Dwp7Yf4l40WCGkm+gQWO2Vs+RF/inpdorYNuOkMoMhUk52ki5Qu0
r0XO29sLEH8LtQNCEem6OfzVadSnCdEQysOI4UIJmQQfclPjrqpFcthqAczgJCrp
dEq48M1ZuBtBuMSWFHx2HEAPaJEdp0ut9+1jhod+PtYb6HcHgmPQ3U00j9ymcUgX
yn3xTA7Wfz+5NMAs/jybLC4Sz/PivZNCCh7jx1DUObsXYe/3mZ+KOBSxhK3ywgc=
=R7RY
-----END PGP SIGNATURE-----
--GvXjxJ+pjyke8COw--
|