public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail•com>
To: Matt Corallo <bitcoin-list@bluematt•me>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] 0.3.24
Date: Thu, 30 Jun 2011 22:07:50 -0400	[thread overview]
Message-ID: <BANLkTi=ZZK5whvEmCj+aqp5q+XBnXZRY2A@mail.gmail.com> (raw)
In-Reply-To: <1309478838.3689.25.camel@Desktop666>

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.



  reply	other threads:[~2011-07-01  2:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01  0:07 Matt Corallo
2011-07-01  2:07 ` Gregory Maxwell [this message]
2011-07-01  2:44   ` Douglas Huff
2011-07-01 12:41   ` Douglas Huff
2011-07-01  8:00 ` Pieter Wuille
2011-07-01  8:39   ` Jeff Garzik
2011-07-01 12:31     ` Gavin Andresen
2011-07-01 12:40       ` Matt Corallo
2011-07-01 15:06         ` Gavin Andresen
2011-07-01 16:35           ` jan
2011-07-01 16:47             ` Robert McKay
2011-07-01 17:47             ` Douglas Huff
2011-07-01 17:50               ` Matt Corallo
2011-07-01 17:52                 ` Douglas Huff
2011-07-01 22:03                 ` Matt Corallo
2011-07-01 22:07                   ` Douglas Huff
2011-07-01 17:59             ` Gregory Maxwell
2011-07-01 23:42           ` Jeff Garzik
2011-07-02  0:37             ` Jeff Garzik
2011-07-02  0:46               ` Matt Corallo
2011-07-02  0:51                 ` Gregory Maxwell
2011-07-02  1:05                 ` Douglas Huff
2011-07-02  1:12                   ` Matt Corallo
2011-07-02  2:05                     ` Gavin Andresen
2011-07-02 21:07                       ` Jeff Garzik
2011-07-03  1:58                         ` Matt Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTi=ZZK5whvEmCj+aqp5q+XBnXZRY2A@mail.gmail.com' \
    --to=gmaxwell@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=bitcoin-list@bluematt$(echo .)me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox