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 B5BFDFC1 for ; Mon, 25 Jan 2016 12:27:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 651018A for ; Mon, 25 Jan 2016 12:27:28 +0000 (UTC) Received: from [77.178.123.142] (helo=anonymous) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1aNgDQ-0001Vv-Ay for bitcoin-dev@lists.linuxfoundation.org; Mon, 25 Jan 2016 13:25:52 +0100 From: xor@freenetproject.org To: bitcoin-dev@lists.linuxfoundation.org Reply-To: xor@freenetproject.org Date: Mon, 25 Jan 2016 13:27:18 +0100 Message-ID: <2815165.aykQg88K5r@1337h4x0r> Organization: Freenet Project User-Agent: KMail/4.13.3 (Linux/3.13.0-76-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20160125120317.GB17769@amethyst.visucore.com> References: <20160117100808.GA4299@amethyst.visucore.com> <1591452.8UA7xN1qih@1337h4x0r> <20160125120317.GB17769@amethyst.visucore.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6301928.ZivuVfnlPZ"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Df-Sender: eG9yQGZyZWVtYWlsLmJvZ2VydC5kZQ== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 25 Jan 2016 13:15:32 +0000 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 12:27:29 -0000 --nextPart6301928.ZivuVfnlPZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Monday, January 25, 2016 01:03:17 PM Wladimir J. van der Laan wrote:= > > If yes, I would highly recommend advertising it in the new release = notes - > > as said, the disk space reduction is a big deal. >=20 > Good idea, has been added by Marco Falke in commit fa31133, Thanks. The RC2 changelog now says: > To enable block pruning set prune=3D on the command line or in > bitcoin.conf, where N is the number of MiB to allot for raw block & u= ndo > data. From=20having read the Bitcoin whitepaper quite a few months ago ago, I h= ave the=20 very very basic understanding that pruning is meant to: =2D delete old transaction data which merely "moves coins around" =2D instead only store the "origin" (=3D block where coins were mined) an= d=20 "current location" of the coins, i.e. the unspent transactions. Notably= , I=20 understood it as "this is as secure as storing everything, since we kno= w where=20 the coins were created, and where they are". So from that point of view, I would assume that there is a "natural" am= ount of=20 megabytes which a fully pruned blockchain consists of: It would be defi= ned by=20 the final amount of unspent coins. I thereby am confused why it is possible to configure a number of megab= ytes=20 "to allot for raw block & undo data". I would rather expect pruning jus= t to be=20 a boolean on/off flag, and the number of megabytes to be an automatical= ly=20 computed result from the natural size of the dataset. And especially, I fear that I could set N too low, and as a result, it = would=20 delete "too much". I mean could this result in even security relevant=20= transaction data being deleted? Thus, it would be nice if you could yet once more edit the release note= s to: =2D explain why a N must be given =2D what a "safe" value of N is. I.e. how large must N be at least to not= delete=20 security-relevant stuff? =2D maybe mention if there is a "auto" setting for N to ensure that it ch= oses a=20 safe value on its own? Sorry if my descriptions are from a layman's point of view. I intention= ally=20 did *not* re-read the Bitcoin whitepaper to have a better understanding= : I think having a layman's understanding is a good usability test for su= ch=20 stuff. --nextPart6301928.ZivuVfnlPZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABCAAGBQJWphSsAAoJEMtmZ+8tjWt5muQQAI2wK/BrEN9VAqJn18obeZOr LLo3N3y9Iz3RXIZ5s3V0Q0l8F+7l55M5tZy4lgFQ5Y0n1G2md9kQKEgKFq0tNbC5 +D2zAemWZWZbQV91+t2WhKI4r8hKh/JuhNk1Bjiyt4IRI6LiaumoxPk/CSge7ifi iSTh22TNhJ6thuEVaNjMTLRDxu1uf0CyxfTG427iz0Rj8MASCQrt81wnGH5RA+LB QXGye8avaosVKvTs+gTAnW6eBI/muFh0uLrDUNpc4xwrmn1ejt+FfHgBGjiNK+fi iF8brEonxzI0e0Ynu/kyaUkbrhIKNM5lPHBIbHAzWtAapZBGZYh0N/hHsPKJZCcf clidX+TvmolbhKjbxKducSmJAA19Z9zBxWgUkatpAJK7DtloX52zpdOISA8av2ZI MC7/qroTAfgOj4pKYUUY6t/ZNFGr99m10R/KBkuwWmq5IiolppqFLEZ+9ZIZTSpU sLH0TOssCYaob4aOXR5ucYWrnSy8HbrHvlJ24ZNnx/3CsxSLAPo8JtgBbw6mnbrf K2kcrwn2Zz4ofdXl32L15BYb3UNgGuKyo8Lsn2q2or0jyx5S+1WKNSHTPsMymrOE tWAeQv/R0UyQXFXMPvAl2Y7Wh3SpV2I3MCSby5bcwa4dW3O6dneaQCEvAyMcVvRu omHzx23XDM4ay9b5TJQ/ =5S1H -----END PGP SIGNATURE----- --nextPart6301928.ZivuVfnlPZ--