From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UHFX3-0002P3-B1 for bitcoin-development@lists.sourceforge.net; Sun, 17 Mar 2013 15:29:57 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UHFX2-0002Dh-6V for bitcoin-development@lists.sourceforge.net; Sun, 17 Mar 2013 15:29:57 +0000 Received: from ishibashi.localnet (unknown [173.170.142.26]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 8ABCF27A2968; Sun, 17 Mar 2013 15:29:50 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net, Gavin Andresen Date: Sun, 17 Mar 2013 15:29:37 +0000 User-Agent: KMail/1.13.7 (Linux/3.7.3-gentoo; KDE/4.9.5; x86_64; ; ) References: <51452473.1040301@gmail.com> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303171529.39725.luke@dashjr.org> X-Spam-Score: -2.5 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -2.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UHFX2-0002Dh-6V Subject: Re: [Bitcoin-development] 0.8.1 plan 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: Sun, 17 Mar 2013 15:29:57 -0000 On Sunday, March 17, 2013 2:20:14 AM Frank F wrote: > Well, he did make the bitcoin.org/may15.html page already. It would be > crazy to change that now. OTOH, the page's recommended config isn't really too ideal. While the new lock limit should be good for up to 2 block deep reorgs, I doubt merchants/miners want to get stuck if someone pulls off a 3-block deep reorg. Since we usually consider 6 blocks to be "confirmed beyond impossibility of reversal", a limit of at least 292692 should probably be recommended. Additionally, I suspect set_lg_max may need bumping upward - but I'm not quite sure how to calculate the correct value there. Why does the example config do set_lg_dir? That will screw things up should the client be using some other directory for any reason.. Also, please add a note that 0.4.x, 0.5.x, 0.6.x, and 0.7.x will be receiving backports in their next stable releases sometime before May 15. Luke