Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Simon Selitsky <simon@coingyft.com>
In-Reply-To: <20160125150559.GA28847@amethyst.visucore.com>
Date: Mon, 25 Jan 2016 10:57:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A118822-6550-4042-9229-1D213B6FE615@coingyft.com>
References: <20160117100808.GA4299@amethyst.visucore.com>
	<1591452.8UA7xN1qih@1337h4x0r>
	<20160125120317.GB17769@amethyst.visucore.com>
	<2815165.aykQg88K5r@1337h4x0r>
	<20160125150559.GA28847@amethyst.visucore.com>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
Precedence: list

>> Block data that is stored can be used by other software, or potentially b=
e
>> served to other nodes. The latter is not implemented at the moment - it w=
ould require a change to the P2P protocol, thus right now pruning nodes don'=
t serve block data at all.

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 tr=
ansaction verification and transaction relaying and only keep the block(s)=20=

being verified on disk ?


On Jan 25, 2016, at 10:05 AM, Wladimir J. van der Laan via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:

>>> 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 & undo=

>>> data.
>=20
>> =46rom having read the Bitcoin whitepaper quite a few months ago ago, I h=
ave the=20
>> very very basic understanding that pruning is meant to:
>> - delete old transaction data which merely "moves coins around"
>> - instead only store the "origin" (=3D block where coins were mined) and=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 know w=
here=20
>> the coins were created, and where they are".
>>=20
>> So from that point of view, I would assume that there is a "natural" amou=
nt of=20
>> megabytes which a fully pruned blockchain consists of: It would be define=
d by=20
>> the final amount of unspent coins.
>> I thereby am confused why it is possible to configure a number of megabyt=
es=20
>> "to allot for raw block & undo data". I would rather expect pruning just t=
o be=20
>> a boolean on/off flag, and the number of megabytes to be an automatically=
=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 wo=
uld=20
>> delete "too much". I mean could this result in even security relevant=20
>> transaction data being deleted?
>=20
> The term 'pruning', unfortunately is very much overused and overloaded in t=
he
> bitcoin ecosystem. Satoshi's paper refers to UTXO pruning. This is Pieter W=
uille's "ultraprune",
> which has been part of Bitcoin Core for more than three years.
>=20
> Block pruning is not mentioned in that paper because it is just administra=
tive,
> the only reason that nodes store historical blocks at all is to serve it t=
o other nodes,
> as well as to catch up the wallet status and for -reindexes.
>=20
>> Thus, it would be nice if you could yet once more edit the release notes t=
o:
>=20
> I don't have time to work on the release notes right now, but if someone e=
lse
> wants to contribute that'd be awesome.
>=20
>> - explain why a N must be given
>=20
> To give a quotum. The point is that the user can choose how much harddisk s=
pace they want to
> dedicate to block storage.
>=20
> Block data that is stored can be used by other software, or potentially be=

> served to other nodes. The latter is not implemented at the moment - it wo=
uld require
> a change to the P2P protocol, thus right now pruning nodes don't serve blo=
ck
> data at all.
>=20
>> - what a "safe" value of N is. I.e. how large must N be at least to not d=
elete=20
>> security-relevant stuff?
>=20
> There is no security compromise with pruning. Any value of N is intended t=
o be safe.
>=20
> Very low values would delete undo data that may be necessary in a reorgani=
zation,
> but this is prohibited by argument checks.
>=20
> Release notes are not meant as a replacement or supplement for documentati=
on.
> The documentation for -prune is this:
>=20
>  -prune=3D<n>
>       Reduce storage requirements by pruning (deleting) old blocks. This m=
ode
>       is incompatible with -txindex and -rescan. Warning: Reverting this
>       setting requires re-downloading the entire blockchain. (default: 0 =3D=

>       disable pruning blocks, >550 =3D target size in MiB to use for block=

>       files)
>=20
>> - maybe mention if there is a "auto" setting for N to ensure that it chos=
es a=20
>> safe value on its own?
>=20
> As said, there is no safe or unsafe value. The lowest acceptable value is j=
ust as safe
> as storing everything.
>=20
> Wladimir
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev