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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1UZO1j-00030T-5S
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 16:12:35 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.108 as permitted sender)
client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
helo=outmail148108.authsmtp.net;
Received: from outmail148108.authsmtp.net ([62.13.148.108])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UZO1h-0004uO-KZ for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 16:12:35 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r46GCQL6046466; Mon, 6 May 2013 17:12:26 +0100 (BST)
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r46GCHrN081318
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 6 May 2013 17:12:19 +0100 (BST)
Date: Mon, 6 May 2013 12:12:16 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130506161216.GA5193@petertodd.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: ba9631bb-b667-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgQUFVQNAgsB AmUbWlNeUV97W2M7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxgH cW1mEGdyfwRFeXY+ Z0RqXngVDhVzc0V8
EBxJR2sAYnphaTUd TRJZd1FJcANIexZF aVN4USYPLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMj8n TBccEC8+WkQJSz97
NxUtKVMABw5RLUwp YxMaVEgGMhQfQgdf A1ovSCFePREZXTct
AA8SW0kSHSYcKQAA
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/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: 1UZO1h-0004uO-KZ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
for pruned nodes)
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, 06 May 2013 16:12:35 -0000
--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, May 06, 2013 at 04:58:56PM +0200, Mike Hearn wrote:
More generally, I think this shows clearly how SPV nodes have weaker
security than constantly operating full nodes, which we knew already, so
why not build a better SPV-specific system instead?
I've noticed on my Android phone how it often takes quite awhile to find
a peer that will actually accept an incoming connection, which isn't
surprising really: why should a regular node care about responding to
SPV nodes quickly?
For fast startup you would be better served with dedicated nodes that
are backed by fast hardware and high bandwidth internet connections.
You can discourage non-SPV use by refusing to relay full blocks.
You can have trusted individuals vouch for these special servers with
SSL certificates so you run less of a risk of connecting to a malicious
one trying to limit what information you see. For the initial
implementation, maybe just make a quick SSL accessible service with HTTP
GET so you don't have to integrate SSL into the network protocol and
have a couple of these HTTP GETable servers running. (IE, the trust is
actually that the SPV seed is honest)
Security will be no worse than before - if any one server/seed is honest
you're ok - and hopefully better due to the accountability. Obviously
you can use the existing bootstrap method in parallel at the same time.
What's good about partitioning between SPV and full node bootstrapping,
is the regular DNS seeds can optimize the other way: accept that some
nodes may turn out to be evil, and limit the damage by returning peers
=66rom the widest pool possible even if some of those peers may be a bit
slow and unreliable. An attacker can't dominate the results by running a
small number of fast reliable nodes because the results returned comes
=66rom a huge pool, so they are stuck with getting access to lots of IP
addresses, and maybe in the future we'll have even better methods of
resisting sybil attacks, and we will be able to implement those methods
even if they mean initial bootstrapping is slower.
> Subject change to reflect that this is off-topic for the old thread.
>=20
> Eventually, I think it makes sense to move to a system where you get seeds
> > from
> > a DNS (or other mechanism), connect to one or a few of the results, do a
> > getaddr,
> > fill your peer IP database with it, and disconnect from the DNS seeded
> > peer.
>=20
>=20
> This obviously makes no difference from a security perspective. If a DNS
> seed is compromised it can feed you nodes that just connect you back to t=
he
> sybil. If you seed from DNS then that's your root of trust.
>=20
> The problem with moving away from DNS seeding for bitcoinj clients at lea=
st
> is that SPV clients are very sensitive to startup time. It isn't OK to
> spend two minutes trying to connect to lots of long-dead IP addresses if
> you're wanting to pay your bill in a restaurant. That means either you ha=
ve
> to spin up a lot of TCP connections in parallel, which I know from bitter
> experience can cause problems with some crappy wifi routers (they think
> it's a synflood), or you get a known fresh source of IPs like a DNS seed
> response and then later on bring up connections to the P2P network from
> that.
>=20
> Implementing the latter is complicated - you have to partition your nodes
> so the seed peers are separated from the peers you found via addr
> broadcasts and seeded peers can't pollute your addr-found peers unless it=
's
> your first run.
>=20
> I've actually not experimented with this for a while. I'm hoping that by
> the time this gets to the top of my todo list, network nodes will be stab=
le
> enough that actually you can always obtain at least one or two connections
> if you try (say) 30 at once. But I have no idea if we're at that stage ye=
t.
> -------------------------------------------------------------------------=
-----
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--=20
'peter'[:-1]@petertodd.org
000000000000002a871dc011fe28fd8fbffe577c02b91d2de09aeca8216644ef
--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlGH1mAACgkQpEFN739thowmqgCdFPcZhP0EUeQkilyyFLq5b9uh
hH0AnAt1Tt8KerZL7uoXBZhCQRYC2f+K
=GWNU
-----END PGP SIGNATURE-----
--HcAYCG3uE/tztfnV--
|
