[bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available

xor at freenetproject.org xor at freenetproject.org
Mon Jan 25 12:27:18 UTC 2016

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.
> Good idea, has been added by Marco Falke in commit fa31133,

Thanks. The RC2 changelog now says:

> To enable block pruning set prune=<N> on the command line or in
> bitcoin.conf, where N is the number of MiB to allot for raw block & undo
> data.

From having read the Bitcoin whitepaper quite a few months ago ago, I have the 
very very basic understanding that pruning is meant to:
- delete old transaction data which merely "moves coins around"
- instead only store the "origin" (= block where coins were mined) and 
"current location" of the coins, i.e. the unspent transactions. Notably, I 
understood it as "this is as secure as storing everything, since we know where 
the coins were created, and where they are".

So from that point of view, I would assume that there is a "natural" amount of 
megabytes which a fully pruned blockchain consists of: It would be defined by 
the final amount of unspent coins.
I thereby am confused why it is possible to configure a number of megabytes 
"to allot for raw block & undo data". I would rather expect pruning just to be 
a boolean on/off flag, and the number of megabytes to be an automatically 
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 
delete "too much". I mean could this result in even security relevant 
transaction data being deleted?

Thus, it would be nice if you could yet once more edit the release notes to:
- explain why a N must be given
- what a "safe" value of N is. I.e. how large must N be at least to not delete 
security-relevant stuff?
- maybe mention if there is a "auto" setting for N to ensure that it choses a 
safe value on its own?

Sorry if my descriptions are from a layman's point of view. I intentionally 
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 such 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160125/87785117/attachment.sig>

More information about the bitcoin-dev mailing list