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 --]
next prev parent 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 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$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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