public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: xor@freenetproject.org
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
Date: Mon, 25 Jan 2016 13:27:18 +0100	[thread overview]
Message-ID: <2815165.aykQg88K5r@1337h4x0r> (raw)
In-Reply-To: <20160125120317.GB17769@amethyst.visucore.com>

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

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 
stuff.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2016-01-25 12:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-17 10:08 [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available Wladimir J. van der Laan
2016-01-17 22:57 ` xor
2016-01-18 11:14   ` Wladimir J. van der Laan
2016-01-19  6:06     ` xor
2016-01-25 12:03       ` Wladimir J. van der Laan
2016-01-25 12:27         ` xor [this message]
2016-01-25 14:44           ` Marco Falke
2016-01-25 15:05           ` Wladimir J. van der Laan
2016-01-25 15:57             ` Simon Selitsky
2016-01-25 16:12               ` Jonas Schnelli
2016-01-25 17:33             ` xor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2815165.aykQg88K5r@1337h4x0r \
    --to=xor@freenetproject.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox