Sender: Doug <mith@jrbobdobbs.org>
References: <1309478838.3689.25.camel@Desktop666>
	<BANLkTi=ZZK5whvEmCj+aqp5q+XBnXZRY2A@mail.gmail.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <BANLkTi=ZZK5whvEmCj+aqp5q+XBnXZRY2A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Douglas Huff <dhuff@jrbobdobbs.org>
Date: Fri, 01 Jul 2011 07:41:02 -0500
To: Gregory Maxwell <gmaxwell@gmail.com>,
	Matt Corallo <bitcoin-list@bluematt.me>
Message-ID: <5d917a01-5502-4f07-a6e6-1fdb8655b470@email.android.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.3.24
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Why off on Linux? If anything Linux has, historically, had the most testing of the miniupnpc library. So it's the most stable of the three.

Gregory Maxwell <gmaxwell@gmail.com> wrote:

>On Thu, Jun 30, 2011 at 8:07 PM, Matt Corallo
><bitcoin-list@bluematt.me> wrote:
>> Due to the flood control limits becoming an issue again, it would
>appear
>> we need a 0.3.24 release.  The idea is to have sipa's flood limit fix
>>
>(https://github.com/sipa/bitcoin/commit/df94ed7ac0ed7bb3a96cf434ca3c64c4b475e37e),
>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 = 262744 listening sockets.
>Meaning, assuming a nice equal distribution we need 2189 listening
>nodes to support the network— 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
>result.
>
>
>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.
>
>------------------------------------------------------------------------------
>All of the data generated in your IT infrastructure is seriously
>valuable.
>Why? It contains a definitive record of application performance,
>security
>threats, fraudulent activity, and more. Splunk takes this data and
>makes
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2d-c2
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

- --
Douglas Huff
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iQIVAwUBTg3AXUPHkQabDWHPAQgI8RAAm4Csyc4jqLvJSpopwNKg20273Hk2dhpR
s0RHerh1TgFDLDeByhzZLX/GC5SzGpPRDllDDlKcXl+E7iS7xtsuB+KbNdjYERmn
eVm67PQnXZ0PaDUnUxywyl55dcM8WAhwAYZKxvY2IzJ5y6oV7aPSDt7+qtXGL5Tx
EWjtQU06EaLhQkamelEc0KhHWqA72S/1VIgITvW4KVOf8SKyfTkxADdvRJ2iEznZ
bemdm81nbNFuYjGng9pEzqs9CVkWthANFa8GhxV9yFiqhpT7rCZKktkmqazxw6le
zog0v0MDfd55eWH59dHd9FbdiU757VMZtjTew3EoKrvIOwj1XQ50aSwaxO2CeTfW
qfW/xrxo+6VJx2kpLC833rvek4nx/7a0YVSvtypp9R1td9wAPi14IT+wOZ6C6ofs
Cg1VtETit4cS4xeHNx5boMayBvqpS1tmYgrTdi0QjmlWa75RDLIIteWcS7Q6NP0r
G2BRm3sqTGo/7Vzhmqn3BWNe5lq21NCW9kMs8nzhntnalF13BdIN4ZMimmSmLb5O
PUzg9OUZ5qfW3rsbYgYXXritzcNSftva+H/sCLIIoFOJO16wpiQXoHjTSY0TwwIT
XrVAcP2sRQjfT5QzPfwHDBRcYDgpfGJs5+jXtPc1maac7AxRjZ0op7gXFb/3L/W4
mQFXl6I9hhg=
=qsYM
-----END PGP SIGNATURE-----