What happens if you set prune=<n> to a value between 0 and 550?

Today I saw a question about what Bitcoin Core would do if you set prune=1. The documentation on bitcoin.org states:

A value of 0 disables pruning. The minimal value above 0 is 550.

Apparently, the log upon setting prune=1 states:

2017-03-11 10:51:03 Block pruning enabled. Use RPC call pruneblockchain(height) to manually prune block and undo files.

Will Bitcoin Core prune to the minimum disk usage now, or does it just enable manual pruning?

The asker was running Bitcoin Core 0.14.0, if it makes a difference.

pruning

Murch

Posted 2017-03-11T11:02:37.833

Reputation: 41 609

Answers

From the Bitcoin Core v0.14.0 release notes:

Bitcoin Core has supported automatically pruning the blockchain since 0.11. Pruning the blockchain allows for significant storage space savings as the vast majority of the downloaded data can be discarded after processing so very little of it remains on the disk.

Manual block pruning can now be enabled by setting -prune=1. Once that is set, the RPC command pruneblockchain can be used to prune the blockchain up to the specified height or timestamp.

So this means that if you set -prune=1, the node will act as a pruned node (not advertize blocks to other nodes), but not actually delete anything. Instead, it enables the pruneblockchain RPC which you can use to manually prune block files after you're done with them. The reason for this is that you may need the block files in some external application, and don't want Bitcoin Core to go delete them from under you.

I assume the documentation on bitcoin.org is out of date.

Pieter Wuille

Posted 2017-03-11T11:02:37.833

Reputation: 54 032

It turns out that prune=1 is a new special case which enables manual pruning. For values of N from 2 to 549, prune=N shows an error.

Bitcoin Core parses configuration arguments in the init.cpp. Depending on the value of prune=<N>:

N < 0 – returns the error: "Prune cannot be configured with a negative value."
N = 1 – Activates manual prune mode as described in Pieter's answer. It causes Bitcoin Core not to advertise blocks anymore and enables the pruneblockchaincommand, but it doesn't automatically prune the blockchain data.
1 < N < 550 – returns the error "Prune configured below the minimum of N MiB. Please use a higher number."
550 ≤ N – Sets N as the limit of MiB available for block data.

Murch

Posted 2017-03-11T11:02:37.833

Reputation: 41 609

What is the benefit of setting prune to be anything greater than 550? – Curt – 2017-05-17T17:52:54.170

You can deliver block information on older blocks and if you try to rescan you can check balances on addresses for a longer period of time into the history without needing to redo the initial synchronization. – Murch – 2017-05-17T18:04:12.697

1this is so confusing... what is the 550 magic number exactly? some stackoverflow answers say it's a block height but here you say it's the number of MiB? if the latter, why 550 MiB is a magic number? – knocte – 2017-07-26T07:26:19.607

1@knocte: It is an amount of data, not a blockheight. However, since blocks are 1MB, I can see why people might think it's a blockheight. I assume it's merely a magic number, which however provides you at least three days worth of blockchain data, for your convenience in case a reorganization occurs. Could you link me to the stackoverflow question please? I might want to add a correction there. – Murch – 2017-07-26T14:56:55.420

@knocte it's actually pretty overkill. Having 550 protects against someone building a chain which is 550 (!!!) blocks longer than the current chain and then invalidating your pruned node. It's nearly impossible and would be a stupid attack – CornSmith – 2017-12-02T22:17:29.430

@CornSmith blocks can be and are bigger than one megabyte. – Murch – 2017-12-03T01:20:20.263

I mean, I'm having trouble finding any data on this, but I'd be very surprised if there was a reorganization bigger than 10 blocks (20MB with segwit) – CornSmith – 2017-12-03T01:56:20.440

@CornSmith: The biggest known reorganization was 31 blocks due to the March 2013 blockchain split. Besides that the longest known reorganization was four blocks according to https://bitcoin.stackexchange.com/q/3343/5406

– Murch – 2017-12-03T22:39:37.193

Cool, that's good info to tuck into my hat, thanks for tracking that down <3 – CornSmith – 2017-12-04T01:28:13.820