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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1QpK3X-0002fP-Jq
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Aug 2011 13:03:15 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
helo=mail-wy0-f175.google.com;
Received: from mail-wy0-f175.google.com ([74.125.82.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QpK3W-000781-Om
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Aug 2011 13:03:15 +0000
Received: by wyf19 with SMTP id 19so270349wyf.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 05 Aug 2011 06:03:08 -0700 (PDT)
Received: by 10.227.146.209 with SMTP id i17mr1808265wbv.28.1312549388329;
Fri, 05 Aug 2011 06:03:08 -0700 (PDT)
Received: from dvr.localnet (mail.360visiontechnology.com [92.42.121.178])
by mx.google.com with ESMTPS id fp3sm2277558wbb.64.2011.08.05.06.03.06
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 05 Aug 2011 06:03:07 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Fri, 5 Aug 2011 14:03:05 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; )
References: <201108041423.14176.andyparkins@gmail.com>
<201108051258.25813.andyparkins@gmail.com>
<1312545969.4516.8.camel@BMThinkPad.lan.bluematt.me>
In-Reply-To: <1312545969.4516.8.camel@BMThinkPad.lan.bluematt.me>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1768847.8MR82ZS5ip";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201108051403.05506.andyparkins@gmail.com>
X-Spam-Score: -1.6 (-)
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
(andyparkins[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QpK3W-000781-Om
Subject: Re: [Bitcoin-development] Double spend detection to speed up
transaction trust
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:03:15 -0000
--nextPart1768847.8MR82ZS5ip
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
On 2011 August 05 Friday, Matt Corallo wrote:
> On Fri, 2011-08-05 at 12:58 +0100, Andy Parkins wrote:
> > I don't really see that "number of connections" is the relevant metric.
>=20
> Number of connections is something that needs serious thought. Too many
> and you fill everyone's connection slots and no one can make
> connections. Too few and you don't have a network but just a bunch of
> islands which would also cause serious problems.
> If you aren't relaying, each connection takes almost no bandwidth, so
> the question is how many do you need to be considered secure.
I'm arguing that "number of connection slots" isn't the best metric; so tha=
t=20
wouldn't matter. Just keep accepting incoming connections (with some sanit=
y=20
limit of course) until you've allocated your bandwidth, not your number of=
=20
connections.
If I connect to a thousand nodes and never send anything, I'm not using up=
=20
very much of their resources. If _they_ want to use up resources by relayi=
ng,=20
then that is their choice, but again they can do that based on bandwidth=20
calculations rather than connection counts. If I am sending, then that add=
s=20
to their bandwidth and gets included in whatever limit they've chosen.
=46or example: the client could simply maintain an average bandwidth over a=
ll=20
connections. If that average is less than threshold0, then make new outgoi=
ng=20
connections. If that average exceeds threshold1, then stop accepting incom=
ing=20
connections. If it exceeds threshold2, start dropping established incoming=
=20
connections. If it exceeds theshold3, start dropping established outgoing=
=20
connections.
The actual rules don't matter so much; I'm just saying bandwidth is a bette=
r=20
metric than connection count. If you limit by connection count, then you'l=
l=20
just end up filled with non-relaying listeners, since they (in the future)=
=20
will be the most commonplace. You'll have no incoming relays, and therefor=
e=20
nothing to forward, so your bandwidth will be zero, but your connection cou=
nt=20
at maximum -- you've locked yourself out.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart1768847.8MR82ZS5ip
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk476gkACgkQwQJ9gE9xL21McQCeM800bGwT7by8dNlp3T2zanjd
LCYAnRjAdCQC2rrbvt+ypZVAJ+TIgMs0
=V3BY
-----END PGP SIGNATURE-----
--nextPart1768847.8MR82ZS5ip--
|
