<blockquote>
  <p>Judging from the docs I understand that pruning, in laymen terms, only allows to get rid of information that cannot have any follow up transaction.</p>
</blockquote>

<p>That's incorrect.</p>

<p>The process for block validation (simplified) is:</p>

<ul>
<li>Receive a block</li>
<li>Find all the block's inputs in the database of unspent outputs (the "UTXO set"), and verify them (signature checking etc)</li>
<li>Remove all the block's inputs from the UTXO set (as those outputs now become spent)</li>
<li>Add all the block's outputs to the UTXO set.</li>
</ul>

<p>Once a block has been validated, and its effects been applied to the UTXO set, we don't generally need the contents of the block anymore, at all. Except for:</p>

<ul>
<li>Giving it to other nodes on the network that are trying to figure out what happened in the past (which you can't do yet when in pruning mode)</li>
<li>Rescanning to find historical transactions in the wallet (e.g. after importing an address or a key), which is a feature you give up when pruning.</li>
<li>Reorganizations. Sometimes a block is found that is not a successor of the previous block we saw, but one that branches off further back. In this case we need to be able to roll back the effects of the last block(s) before validating the new block(s). In order to roll back, we do need the contents of the blocks again. This is the reason why the client forces you to keep at least 550 MB of block data, so that you can always rewind the last few days.</li>
</ul>

<p>So TL;DR: It's technically possible to create a client that prunes to an arbitrarily small value, but to prevent clients from tripping over when a reorganization happens, the code forces you to keep a few days worth of data regardless.</p>

CC BY-SA 3.0
2017-05-03T23:13:53.507Z
2017-05-03T23:23:36.323Z
2017-05-03T23:23:36.323Z
Pieter Wuille
<p>Judging from the docs I understand that pruning, in laymen terms, only allows to get rid of information that cannot have any follow up transaction.</p>

<p>Now, how/why is it possible to set the <code>prune</code> option to a custom value?</p>

<p>What if 550 MiB would be too small, "cutting out" important information?</p>

<bitcoind><bitcoin-core><pruning>
How does the prune target size work?
user569825
# How does the prune target size work?

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

Judging from the docs I understand that pruning, in laymen terms, only allows to get rid of information that cannot have any follow up transaction.

Now, how/why is it possible to set the `prune` option to a custom value?

What if 550 MiB would be too small, "cutting out" important information?

**Tags:** bitcoind, bitcoin-core, pruning


---

## 1 answers

### Answer by username_1 on 2017-05-03. Score: 3 | Accepted answer

> Judging from the docs I understand that pruning, in laymen terms, only allows to get rid of information that cannot have any follow up transaction.

That's incorrect.

The process for block validation (simplified) is:

* Receive a block
* Find all the block's inputs in the database of unspent outputs (the "UTXO set"), and verify them (signature checking etc)
* Remove all the block's inputs from the UTXO set (as those outputs now become spent)
* Add all the block's outputs to the UTXO set.

Once a block has been validated, and its effects been applied to the UTXO set, we don't generally need the contents of the block anymore, at all. Except for:

* Giving it to other nodes on the network that are trying to figure out what happened in the past (which you can't do yet when in pruning mode)
* Rescanning to find historical transactions in the wallet (e.g. after importing an address or a key), which is a feature you give up when pruning.
* Reorganizations. Sometimes a block is found that is not a successor of the previous block we saw, but one that branches off further back. In this case we need to be able to roll back the effects of the last block(s) before validating the new block(s). In order to roll back, we do need the contents of the blocks again. This is the reason why the client forces you to keep at least 550 MB of block data, so that you can always rewind the last few days.

So TL;DR: It's technically possible to create a client that prunes to an arbitrarily small value, but to prevent clients from tripping over when a reorganization happens, the code forces you to keep a few days worth of data regardless.


---

