public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Marco Falke <falke.marco@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
Date: Mon, 25 Jan 2016 15:44:08 +0100	[thread overview]
Message-ID: <CAKJqnrGq41ZvGByfH53n1=wJtPZghk+zyNOwZX8RXbJWcr=Xog@mail.gmail.com> (raw)
In-Reply-To: <2815165.aykQg88K5r@1337h4x0r>

All of this is already implemented in the bitcoind and bitcoin gui.

The theoretic minimum for the prune target would be 0 (just the header
of the current best block) as Bitcoin Core already stores the
chainstate (about 2 GiB) regardless of what you set for -prune=<N>.

In practice, the minimum is 510, so reorgs and small rescans (may not
be implemented in 0.12) are still possible.

The clients won't let you set it below that target:
"Prune configured below the minimum of 550 MiB. Please use a higher number."

Also, keep in mind Bitcoin Core comes with a help message explaining
-prune and other command line options

--Marco

2016-01-25 13:27 GMT+01:00 xor--- via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>:
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


  reply	other threads:[~2016-01-25 14:44 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
2016-01-25 14:44           ` Marco Falke [this message]
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='CAKJqnrGq41ZvGByfH53n1=wJtPZghk+zyNOwZX8RXbJWcr=Xog@mail.gmail.com' \
    --to=falke.marco@gmail.com \
    --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