As discussed in the mailing list thread
[bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
in the replies to this message: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012276.html
Please review thoroughly, I'm a newbie.
As discussed in the mailing list thread:
[bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
in the replies to this message:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012276.html
Please review thoroughly, I'm a newbie.
Peter Todd says it does not matter currently.
Jonas Schnelli recommended this to account for growth of utxo set, debug
log, etc.
266 | @@ -267,6 +267,9 @@ Wallet: Pruning 267 | --------------- 268 | 269 | With 0.12 it is possible to use wallet functionality in pruned mode. 270 | +This can reduce the disk usage from currently around 60 GB to 271 | +less than 1 GB.
Around 2GB (also count the utxo set).
Thanks. Fixed by 46d7eb61372d4a507bf80924d1e19dafd46b8da1.
281 | +wallet is as secure with high values as it is with low ones. Higher 282 | +values merely reduce the network traffic in case of reorganization of 283 | +the blockchain. In future releases, a higher value may also help the 284 | +network as a whole: The stored blocks could be served to other nodes. 285 | +Currently, nodes with pruning enabled do not serve block data at all 286 | +and thus could be considered as "leechers".
I think we should remove that last sentence for now, as we're not in a position where "leaching" of blockchain data distribution bandwidth matters.
Thanks. Fixed by be4b474287d6a3479678b6c0ef50587f49bfbc54
266 | @@ -267,6 +267,9 @@ Wallet: Pruning 267 | --------------- 268 | 269 | With 0.12 it is possible to use wallet functionality in pruned mode. 270 | +This can reduce the disk usage from currently around 60 GB to 271 | +less than 2 GB.
I would prefer using "around 2 GB" to avoid an outdated document if utxo set, debug log, etc. grows.
Thanks. Fixed by 58e3abfffc69eaa5ea24f40f8428be48808ca664
276 | @@ -274,6 +277,12 @@ To enable block pruning set `prune=<N>` on the command line or in 277 | `bitcoin.conf`, where `N` is the number of MiB to allot for 278 | raw block & undo data. 279 | 280 | +A value of 0 disables pruning. The minimal value above 0 is 550. Your 281 | +wallet is as secure with high values as it is with low ones. Higher 282 | +values merely reduce the network traffic in case of reorganization of 283 | +the blockchain. In future releases, a higher value may also help the 284 | +network as a whole: The stored blocks could be served to other nodes.
help the network as a whole: stored blocks...
Thanks. Fixed by a683d20d5f88f0685cdacdcba928d6ec572390dd
276 | @@ -274,6 +277,12 @@ To enable block pruning set `prune=<N>` on the command line or in 277 | `bitcoin.conf`, where `N` is the number of MiB to allot for 278 | raw block & undo data. 279 | 280 | +A value of 0 disables pruning. The minimal value above 0 is 550. Your 281 | +wallet is as secure with high values as it is with low ones. Higher 282 | +values merely reduce the network traffic in case of reorganization of
I think this is a confusing sentence. Choosing a larger value means that a node can recover from larger reorgs; however the minimum value of 550MiB is designed to allow for reorgs up to 288 blocks (~2 days).
If there happened to be a reorg that required more data on disk than the user had (very unlikely) then the user's node will crash, and the user would have to restart the node with -reindex. In the case of a node that was pruned, running -reindex will cause the node to delete all the data on disk, which can't (currently) be used by bitcoind when doing a -reindex. So in particular the user will end up redownloading the whole blockchain in such a scenario (the amount re-downloaded will not depend on the value passed to -prune -- unless somehow the user selects a value large enough that all the block files remained on disk and no pruning actually took place).
Rather than try to re-explain pruning here, maybe it would make sense to refer readers back to the 0.11.0 release notes? I don't know how easy that is to link to I guess.
I agree this misunderstands things a bit. The minimum value is chosen to handle any realistic reorganization. Larger reorgs will be disastrous for many other reasons, so there's no need to even consider them here.
If you want to link to older release notes the best way, I think, would be to link to the historical release notes in master: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.11.0.md#block-file-pruning . Alternatively you can link to the current release notes at the time of the v0.11.0 tag: https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning These are probably the same but may potentially be missing some post-facto editorial fixes.
Thanks for your explanations. Fixed by 54d390780feaef895fede8da3f436b932af29c1d
With regards to the multiple options of resolving this, here's what I decided:
Rather than try to re-explain pruning here, maybe it would make sense to refer readers back to the 0.11.0 release notes? I don't know how easy that is to link to I guess.
I think it makes sense to explain it here for the usability purpose of having a self-contained document. However, linking the old release notes also is useful. So I just did both.
I agree this misunderstands things a bit. The minimum value is chosen to handle any realistic reorganization. Larger reorgs will be disastrous for many other reasons, so there's no need to even consider them here.
If the node can crash, that is worth mentioning at least? For example, it could cause financial loss for miners if their nodes shut down. To find a tradeoff between your suggestion of not mentioning it at all, and the "crash + reindex required" information, I tried to keep it as neutral as possible by saying the node will "shutdown" (spelling of that word fixed in 15c0263ff1e4f4773005291e1eb584954900e197), and leaving out what has to be done afterwards. That both conveys the information that it won't work anymore, and allows leaving out what happens afterwards by not scaring the user off with a strong word such as "crash".
If you want to link to older release notes the best way, I think, would be to link to the historical release notes in master: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.11.0.md#block-file-pruning . Alternatively you can link to the current release notes at the time of the v0.11.0 tag: https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning These are probably the same but may potentially be missing some post-facto editorial fixes.
With regards to technical documentation, I think non-permanent links are an annoyance: They make it difficult to reconstruct what a user did read, since the document he saw will vary depending on when he accessed the link. So I chose to link the tag. Luckily, the two files are binary equivalent currently anyway.
Concept ACK
276 | @@ -274,6 +277,17 @@ To enable block pruning set `prune=<N>` on the command line or in 277 | `bitcoin.conf`, where `N` is the number of MiB to allot for 278 | raw block & undo data. 279 | 280 | +A value of 0 disables pruning. The minimal value above 0 is 550. Your 281 | +wallet is as secure with high values as it is with low ones. Higher 282 | +values merely ensure that your node will not shut down upon blockchain 283 | +reorganizations of more than 2 days - which are unlikely to happen in 284 | +practice unless there is a hard fork. In future releases, a higher value
I would strike "unless there is a hard fork" from this sentence; hard forks shouldn't have much bearing on the likelihood of a 288 block reorg, and regardless it's sufficient to point out that large reorgs like this are very unlikely.
Thanks! Fixed by 8c5f90306c12142586024023785f20cac7b22055
Looks better -- utACK apart from my one comment.
Thanks, looks good to me now, going to merge.