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 <[email protected]>: > 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 > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
