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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1QcT9C-0002qT-Og
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Jul 2011 02:07:58 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
helo=mail-qy0-f175.google.com;
Received: from mail-qy0-f175.google.com ([209.85.216.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QcT9A-0002ub-BJ
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Jul 2011 02:07:58 +0000
Received: by qyk30 with SMTP id 30so462495qyk.13
for <bitcoin-development@lists.sourceforge.net>;
Thu, 30 Jun 2011 19:07:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.98.20 with SMTP id o20mr2076221qcn.216.1309486070834; Thu,
30 Jun 2011 19:07:50 -0700 (PDT)
Received: by 10.229.2.194 with HTTP; Thu, 30 Jun 2011 19:07:50 -0700 (PDT)
In-Reply-To: <1309478838.3689.25.camel@Desktop666>
References: <1309478838.3689.25.camel@Desktop666>
Date: Thu, 30 Jun 2011 22:07:50 -0400
Message-ID: <BANLkTi=ZZK5whvEmCj+aqp5q+XBnXZRY2A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
(gmaxwell[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 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QcT9A-0002ub-BJ
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.3.24
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, 01 Jul 2011 02:07:58 -0000
On Thu, Jun 30, 2011 at 8:07 PM, Matt Corallo <bitcoin-list@bluematt.me> wr=
ote:
> Due to the flood control limits becoming an issue again, it would appear
> we need a 0.3.24 release. =C2=A0The idea is to have sipa's flood limit fi=
x
> (https://github.com/sipa/bitcoin/commit/df94ed7ac0ed7bb3a96cf434ca3c64c4b=
475e37e), dnsseed on by default, and maybe UPnP enabled by default as well.
*Flood fix
I think this is important, slow bringups are problematic and I think
the flood disconnects have been contributing to network partitioning
(you'll disconnect nodes that have the full blockchain but keep ones
that don't), adding to the partitioning problems cause elsewhere.
I've been running it for a couple hours on a large public node which
was seeing frequent flood disconnects, and it seems to be working
fine. No more flood disconnects.
Syncing a local node to it (no a not terribly fast core) now takes
34.5 minutes (I new bringup on the same system a few days ago hadn't
synced in over an hour).
Increasing the nLimit in sipa's code from 500 to 5000 reduced the
syncup time for me by about 1.5 minutes, almost all of the speedup
being in the early blocks. Since it has the 5MB limit now I don't see
much reason for a large per block limit.
*Dnsseed
I've been using this for a while, we need more dnsseed roots but I see
no reason not to turn it on now.
*UPNP
Lfnet now reports 32843. Presumably there are more bitcoin users than
that, because not all use IRC. 32843*8 =3D 262744 listening sockets.
Meaning, assuming a nice equal distribution we need 2189 listening
nodes to support the network=E2=80=94 but the real distribution will be
somewhat uneven due to bad luck and the /16 limit.
Matt has estimated that there are around 4000 stable listening nodes.
Linear extrapolation from the two day lfnet growth leave us running
out of sockets in a little more than a month. While it won't all break
if it runs out, since we don't strictly need 8 connections, it's still
not good.
I think getting more listening nodes is a somewhat urgent matter as a resul=
t.
I'd also like suggest updating the checkpoint in 0.3.24. Difficulty
has increased almost 17x since the highest one currently in there. A
rather large number of parties could mine pretty nice forks at 1/16th
the current difficulty for nodes that they've sibyled.
|
