>> Block data that is stored can be used by other software, or potentially be >> served to other nodes. The latter is not implemented at the moment - it >> would require a change to the P2P protocol, thus right now pruning nodes >> don't serve block data at all.
Why is the minimum storage quota of 550 MiB necessary for pruning nodes if the block data is not served to other nodes ? Could the client just do transaction verification and transaction relaying and only keep the block(s) being verified on disk ? On Jan 25, 2016, at 10:05 AM, Wladimir J. van der Laan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> 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? > > The term 'pruning', unfortunately is very much overused and overloaded in the > bitcoin ecosystem. Satoshi's paper refers to UTXO pruning. This is Pieter > Wuille's "ultraprune", > which has been part of Bitcoin Core for more than three years. > > Block pruning is not mentioned in that paper because it is just > administrative, > the only reason that nodes store historical blocks at all is to serve it to > other nodes, > as well as to catch up the wallet status and for -reindexes. > >> Thus, it would be nice if you could yet once more edit the release notes to: > > I don't have time to work on the release notes right now, but if someone else > wants to contribute that'd be awesome. > >> - explain why a N must be given > > To give a quotum. The point is that the user can choose how much harddisk > space they want to > dedicate to block storage. > > Block data that is stored can be used by other software, or potentially be > served to other nodes. The latter is not implemented at the moment - it would > require > a change to the P2P protocol, thus right now pruning nodes don't serve block > data at all. > >> - what a "safe" value of N is. I.e. how large must N be at least to not >> delete >> security-relevant stuff? > > There is no security compromise with pruning. Any value of N is intended to > be safe. > > Very low values would delete undo data that may be necessary in a > reorganization, > but this is prohibited by argument checks. > > Release notes are not meant as a replacement or supplement for documentation. > The documentation for -prune is this: > > -prune=<n> > Reduce storage requirements by pruning (deleting) old blocks. This mode > is incompatible with -txindex and -rescan. Warning: Reverting this > setting requires re-downloading the entire blockchain. (default: 0 = > disable pruning blocks, >550 = target size in MiB to use for block > files) > >> - maybe mention if there is a "auto" setting for N to ensure that it choses >> a >> safe value on its own? > > As said, there is no safe or unsafe value. The lowest acceptable value is > just as safe > as storing everything. > > Wladimir > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
