full-node: Add info on setting node to prune to reduce storage

[wbnns]

This PR adds additional info to the Running a Full Node page regarding how to configure a node to prune in order to reduce storage requirements:

Unless others object, this will be merged on Wednesday, January 4th.

[theymos]

It might be good to also mention that -rescan is disabled as well.

Does SegWit change the 550 MB limit? Blocks will be bigger after SegWit.

I don't object to adding this, but it might become slightly worrisome if nearly everyone starts running with pruning. The P2P network currently doesn't handle this very well.

[wbnns]

@theymos Hey, thanks - just pushed an additional commit to add a note regarding -rescan and included -txindex along with it as well.

I was under the impression that SegWit doesn't have any effect on the minimum pruning configuration but am double-checking. I also reached out to @harding for feedback. He mentioned a separate revision that might need to be made, in that he is able to use importaddress while in pruning mode. The statement about RPCs in the release notes for 0.12.0 may not be correct.

Will update that too in this PR, if so. 👍

[harding]

Nitpicks: I think either the <> should be removed from the prune=<N> or they should be added to the N so that it's clear that they shouldn't be part of the actual entry. Also I think & should be and in regular paragraph text.

[wbnns]

Updated to incorporate these suggestions.

[harding]

Thanks for creating this, @wbnns! I left one comment on the diff and I have some more information below that might be useful.

Disabled RPCs in pruned mode

The RPCs listed as disabled were later re-enabled by the following commit which allows them to function if no rescan is requested. As a regular user of a pruned hot wallet that I also use as a watching-only monitor for my cold wallet, I can confirm that importaddress has worked for me on the 0.12.x releases and importpubkey has worked for me on 0.13.1.

commit 77c60724733a98af5248fb95625046a5a3f82dc3
Author: Gregory Maxwell <greg@__redacted__>
Date:   Mon Sep 7 01:28:32 2015 +0000

    Enable wallet key imports without rescan in pruned mode.
    
    Complete rescan is incompatible with pruning, but rescan is optional on
     our wallet key import RPCs.  Import on use is very useful in some common
     situations in conjunction with pruning, e.g. merchant payment tracking.
    
    This reenables importprivkey/importaddress/importpubkey when rescan
     is not used.
    
    In the future we should consider changing the rescan argument to allow depth
     or date to allow limited rescanning when compatible with the retained
     block depth.

(import|remove)prunedfunds RPCs

I think these two RPCs should also be mentioned in the documentation:

(venv)harding@redspot:~$ bitcoin-cli help importprunedfunds
importprunedfunds

Imports funds without rescan. Corresponding address or script must previously be included in wallet. Aimed towards pruned wallets. The end-user is responsible to import additional transactions that subsequently spend the imported outputs or rescan after the point in the blockchain the transaction is included.

Arguments:
1. "rawtransaction" (string, required) A raw transaction in hex funding an already-existing address in wallet
2. "txoutproof"     (string, required) The hex output from gettxoutproof that contains the transaction




(venv)harding@redspot:~$ bitcoin-cli help removeprunedfunds
removeprunedfunds "txid"

Deletes the specified transaction from the wallet. Meant for use with pruned wallets and as a companion to importprunedfunds. This will effect wallet balances.

Arguments:
1. "txid"           (string, required) The hex-encoded id of the transaction you are deleting

Examples:
> bitcoin-cli removeprunedfunds "a8d0c0184dde994a09ec054286f1ce581bebf46446a512166eae7628734ea0a5"

As a JSON-RPC call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "removprunedfunds", "params": ["a8d0c0184dde994a09ec054286f1ce581bebf46446a512166eae7628734ea0a5"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

550 megabyte minimum block store and segwit

I checked the code, and this minimum is unchanged with regard to segwit. Here's the relevant code comment and constant:

// Require that user allocate at least 550MB for block & undo files (blk???.dat and rev???.dat)
// At 1MB per block, 288 blocks = 288MB.
// Add 15% for Undo data = 331MB
// Add 20% for Orphan block rate = 397MB
// We want the low water mark after pruning to be at least 397 MB and since we prune in
// full block file chunks, we need the high water mark which triggers the prune to be
// one 128MB block file + added 15% undo data = 147MB greater for a total of 545MB
// Setting the target to > than 550MB will make it likely we can respect the target.
static const uint64_t MIN_DISK_SPACE_FOR_BLOCK_FILES = 550 * 1024 * 1024;

The codebase includes an integration test (qa/rpc-tests/pruning.py) that create a chain of more than 550 MiB (plus some extra that is needed to trigger the pruning, since it only runs when a new chunk is allocated) and tests that the pruning actual activates. This test is run on regtest, which in recent releases has segwit enabled.

Under segwit, the maximum block size is somewhat less than 4 MiB and I'd guess that the undo data is somewhat larger in the typical case (as there will be more tx-per-block in the typical case) and the orphan blocks are also larger, so I'd guess that in the worst case (4 MiB blocks) we're looking at about half a day worth of blocks and in the expected case (~2 MiB blocks) we're looking at a day worth of blocks.

Perhaps it would be worth strengthening the language in the final paragraph to encourage more people to run with higher values than the minimal.

P2P network concerns

@theymos are you aware that pruned nodes do relay new blocks? (I ask because I used to think that they didn't until I was corrected.) Pruned nodes will also relay transactions like any other node.

This should mean that an always-on node that enables pruning shouldn't change the network dynamics significantly with regard to other always-on nodes. Pruning then only reduces the capacity available to nodes who are in IBD or who are catching up, but I think it's fair (but not ideal) for those nodes to wait---especially when the alternative to people using pruning is probably them not running a node at all, which likely means fewer economic full nodes and thus less security against dishonest mining.

In addition, if there's a disruptive loss of capacity in serving historic blocks that's probably a problem we can fix easily and immediately in the short term by a few Bitcoin supporters buying a bunch of bandwidth (which, though not cheap, is not terribly expensive in data centers) for bolstering network capacity to serve historic blocks. Meanwhile, hopefully that will put the spurs into efforts to allow pruned nodes to each serve a subset of historic blocks.

IMO, we should be promoting pruning more because it's a path to more people running economic full nodes.

Updating release notes

@wbnns Please don't edit the release notes (except for formatting issues) unless the note is changed first in the Bitcoin Core repository.

Thanks again for making this PR!

[wbnns]

@harding Thanks! I revised the copy as per your suggestions. Also, yeah, not touching the release notes. Was referring to fixing the full node page. 👍

[harding]

a133c22 LGTM. Thanks!