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; 
MIME-Version: 1.0
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
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.3.24
Precedence: list

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.