From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3D01D10EF for ; Mon, 25 Jan 2016 16:12:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id A73F779 for ; Mon, 25 Jan 2016 16:12:06 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id ED33F2E6048D; Mon, 25 Jan 2016 17:12:04 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro.local (84-73-32-8.dclient.hispeed.ch [84.73.32.8]) by server3 (Postfix) with ESMTPSA id 46F3B2D0039D for ; Mon, 25 Jan 2016 17:12:04 +0100 (CET) To: bitcoin-dev@lists.linuxfoundation.org References: <20160117100808.GA4299@amethyst.visucore.com> <1591452.8UA7xN1qih@1337h4x0r> <20160125120317.GB17769@amethyst.visucore.com> <2815165.aykQg88K5r@1337h4x0r> <20160125150559.GA28847@amethyst.visucore.com> <2A118822-6550-4042-9229-1D213B6FE615@coingyft.com> From: Jonas Schnelli Message-ID: <56A64951.7040405@jonasschnelli.ch> Date: Mon, 25 Jan 2016 17:12:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <2A118822-6550-4042-9229-1D213B6FE615@coingyft.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 16:12:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Why is the minimum storage quota of 550 MiB necessary for pruning > nodes if the block data is not served to other nodes ? Could the > client just do transaction verification and transaction relaying > and only keep the block(s) being verified on disk ? > We try to allow reorgs ~288 blocks deep also in pruning: - From code comments: Require that user allocate at least 550MB for block & undo files (blk???.dat and rev???.dat) At 1MB per block, 288 blocks = 288MB. Add 15% for Undo data = 331MB Add 20% for Orphan block rate = 397MB We want the low water mark after pruning to be at least 397 MB and since we prune in full block file chunks, we need the high water mark which triggers the prune to be one 128MB block file + added 15% undo data = 147MB greater for a total of 545MB Setting the target to > than 550MB will make it likely we can respect the target. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWpklQAAoJECnUvLZBb1Ps464P+gNqN+Rs5MnAFg5Hukxcj9BU f+Zm5B99VMT3qWjJUjk05NTPLoa6vS6I6pkanWNlzmquZSardW0rW/7JS8wu8BiA ILP3gMWMiF2w//0o+4uEhQt5FhUKQGUVgtXDprc/6WeOfpEBunk+/YTmFPpSMQym w9roH+vrMBHNogSXjdIsn3qPGdVWWuc1PeeluMthN/f7Y5Y5kcyUJvvJmhNbNspG UaGqh7vCDBvaHmxKuPRvqPlSqvwXjA3kxDP1s+VBtLGKnJzVoBqBEsody0UscQQO RRvxbEdaRL1iTVgA0orsDCOMsBaUcKiZ4tlJUd+Z+ifHCVJ5Szl5fsqIIElF8vOk hy8++T4XqPEZqlDnAIpOxE0eGnByvdkUrFew60nA+A+ivY7GkCFhMz8AP4VHrhFS UOU2wDuBOsA6ssqkxMmc5Vizyb6CmL2Ho0csPqabvfRYk5VZACc63FbJ2xcdjDZz CufvfJZ3O5dgSy29fn9XQHsU8qSn0DteSU/9OiHAJmvkqrvB0yT21kIQXUWiqYGk xDvc/SVpttYqaW2hAgjFG9NGJ/D2dpliYNUjgwmijUVZuI9bkJ68l5CfpOzXYnNJ e1AFzBeHVCKSn0advmTVdyybslU32g7ytzJQcQP2b8a4GQYEI6DNhTA5HTxWaj// O+Cm0CkAbW1vNJqSolnU =lDcA -----END PGP SIGNATURE-----