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

<p>Bitcoin Core parses configuration arguments in the <a href="https://github.com/bitcoin/bitcoin/blob/30ff3a2fc95ca6e5b87e6d0f86e54ed9069dae5e/src/init.cpp#L973" rel="noreferrer">init.cpp</a>. Depending on the value of <code>prune=&lt;N&gt;</code>:</p>

<ul>
<li><code>N &lt; 0</code> – returns the error: "Prune cannot be configured with a negative value."  </li>
<li><code>N = 1</code> – Activates manual prune mode as described in <a href="https://bitcoin.stackexchange.com/a/52050/5406">Pieter's answer</a>. It causes Bitcoin Core not to advertise blocks anymore and enables the <code>pruneblockchain</code>command, but it doesn't automatically prune the blockchain data.</li>
<li><code>1 &lt; N &lt; 550</code> – returns the error "Prune configured below the minimum of <code>N</code> MiB.  Please use a higher number."</li>
<li><code>550 ≤ N</code> – Sets <code>N</code> as the limit of MiB available for block data.</li>
</ul>

CC BY-SA 3.0
2017-05-17T17:52:54.170Z
What is the benefit of setting prune to be anything greater than 550?
Curt
CC BY-SA 3.0
2017-05-17T18:04:12.697Z
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
CC BY-SA 3.0
2017-07-26T07:26:19.607Z
this 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
CC BY-SA 3.0
2017-07-26T14:56:55.420Z
@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
CC BY-SA 3.0
2017-12-02T22:17:29.430Z
@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
CC BY-SA 3.0
2017-12-03T01:20:20.263Z
@CornSmith blocks can be and are bigger than one megabyte.
Murch
CC BY-SA 3.0
2017-12-03T01:56:20.440Z
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
CC BY-SA 3.0
2017-12-03T22:39:37.193Z
@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
CC BY-SA 3.0
2017-12-04T01:28:13.820Z
Cool, that's good info to tuck into my hat, thanks for tracking that down <3
CornSmith
CC BY-SA 3.0
2017-03-12T11:42:49.483Z
2017-03-15T13:35:29.797Z
2017-04-13T12:47:33.660Z
Murch
<p>From the <a href="https://bitcoin.org/en/release/v0.14.0" rel="noreferrer">Bitcoin Core v0.14.0 release notes</a>:</p>

<blockquote>
  <p>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.</p>
  
  <p>Manual block pruning can now be enabled by setting <code>-prune=1</code>. Once that is set, the RPC command <code>pruneblockchain</code> can be used to prune the blockchain up to the specified height or timestamp.</p>
</blockquote>

<p>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 <code>pruneblockchain</code> 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.</p>

<p>I assume the documentation on bitcoin.org is out of date.</p>

CC BY-SA 3.0
2017-03-11T19:35:40.927Z
2017-03-11T19:35:40.927Z
Pieter Wuille
<p>Today I saw a question about what Bitcoin Core would do if you set <code>prune=1</code>. The documentation on <a href="https://bitcoin.org/en/full-node#reduce-storage" rel="noreferrer">bitcoin.org</a> states: </p>

<blockquote>
  <p>A value of <code>0</code> disables pruning. The minimal value above <code>0</code> is <code>550</code>.</p>
</blockquote>

<p>Apparently, the log upon setting <code>prune=1</code> states:</p>

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

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

<p>The asker was running Bitcoin Core 0.14.0, if it makes a difference.</p>

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

(Asked by: username_0 on 2017-03-11)

Today I saw a question about what Bitcoin Core would do if you set `prune=1`. The documentation on [bitcoin.org](https://bitcoin.org/en/full-node#reduce-storage) 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.

**Tags:** pruning


---

## 2 answers

### Answer by username_4 on 2017-03-11. Score: 5 | Accepted answer

From the [Bitcoin Core v0.14.0 release notes](https://bitcoin.org/en/release/v0.14.0):

> 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.


---

### Answer by username_0 on 2017-03-12. Score: 6

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](https://github.com/bitcoin/bitcoin/blob/30ff3a2fc95ca6e5b87e6d0f86e54ed9069dae5e/src/init.cpp#L973). 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 [username_4's answer](https://bitcoin.stackexchange.com/a/52050/5406). It causes Bitcoin Core not to advertise blocks anymore and enables the `pruneblockchain`command, 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.

> **Comments:**
> **username_1**: What is the benefit of setting prune to be anything greater than 550?  
> **username_0**: 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.  
> **username_2**: this 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?  
> **username_0**: @username_2: 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.  
> **username_3**: @username_2 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  
> **username_0**: @username_3 blocks can be and are bigger than one megabyte.  
> **username_3**: 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)  
> **username_0**: @username_3: 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  
> **username_3**: Cool, that's good info to tuck into my hat, thanks for tracking that down <3  

---

