From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: Gregory Maxwell To: Matt Corallo 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 02:07:58 -0000 On Thu, Jun 30, 2011 at 8:07 PM, Matt Corallo 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.