Return-Path: <xor@freenetproject.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B5BFDFC1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <xor@freenetproject.org>) 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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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<N> 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--