<p>Since Bitcoin Core v0.8.0, the validation database ("chainstate" or "UTXO set", or "account balance sheet") is separated from the blockchain. When a new block comes in, its effects (removing spent inputs, and adding outputs) are applied to the database. This means blocks are still downloaded and verified like before, but they aren't used for validation anymore afterwards. Blocks are still stored on disk in order to send them to other nodes that are synchronizing, or to rescan for old transactions.</p>

<p>Since Bitcoin Core v0.11.0, it is also possible to run in a true pruned mode, where the blocks on disk are actually deleted after a while. Since v0.12 it is possible to use the wallet while running in pruning mode. Since v0.14 it is possible to manually prune (by issuing an RPC command rather than have the application decide).</p>

<p>Note that neither of these mechanisms rely on the mechanism described in the Bitcoin whitepaper.</p>

CC BY-SA 3.0
2017-04-25T02:55:19.810Z
Related: https://bitcoin.stackexchange.com/questions/37496/how-can-i-run-bitcoind-in-pruning-mode
Highly Irregular
CC BY-SA 3.0
2017-04-24T08:37:29.163Z
2017-04-25T14:12:33.900Z
2017-04-25T14:12:33.900Z
Pieter Wuille
<p>I would assume this is not implemented because of the problem that Pieter mentioned. Having a client that only stores a pruned version of the block chain can't be friendly to other clients that don't have this pruning feature implemented since it won't be able to retrieve the original block chain.</p>

<p>Since a variety of clients are still undergoing development allowing alternative clients the choice of how to handle their block chain data allows for new innovations. For instance, it allows analysis of how Bitcoin has behaved over time. Even if you have not recorded this from the start.</p>

CC BY-SA 3.0
2012-04-20T08:44:11.293Z
2012-04-20T08:44:11.293Z
Beanow
<p>Here are two options.
The first can be blockchain pool which will be torrent like storage and can be implemented independently in wallets (today's 30GB spread to 2000 clients with 50% redundancy will cause only 30MB size)</p>

<p>Second could be some kind of defragmentation, where is needed development of protocol. Here will be no problem to add block on the top of blockchain which includes let say 100k oldest blocks as a copy, without zero balance accounts. Question is only if here will be significant rate of defragmentation.
assumptions</p>

<ul>
<li>we do not need transactions which creates empty accounts (all was sent)</li>
<li>we do not need transactions which do not change balance  (all was sent back)</li>
<li>we can set some time limit to dead accounts (only one transaction topped ou account and account never been used)</li>
</ul>

<p>It is not simple solution and inactive account can not be refreshed until they are not running, then the last item is not quite safe.</p>

CC BY-SA 3.0
2015-03-02T13:04:19.480Z
2015-03-02T13:04:19.480Z
ANT-Z
<p>No, it requires the entire history to verify new transactions (due to how the security of a new block in the chain requires the security of all previous blocks).</p>

<p>Some future client may not require the whole chain and not fully verify transactions, however I would not consider these secure for large transactions because I have no clue if the "skinny client" I'm on is not stuck on a malicious fork in the chain designed to allow double spends and someone has not ran off to Mexico with my Bitcoins.</p>

CC BY-SA 3.0
2012-03-31T12:46:48.097Z
This is not correct. You do not need the entire history to verify transactions - spent and well-buried transactions could safely be removed if it were implemented. With the current network protocol, such a pruned node is not able to provide the block chain to other full nodes, however.
Pieter Wuille
CC BY-SA 3.0
2012-03-30T14:25:59.400Z
2012-03-30T14:25:59.400Z
Diablo-D3
<p>The original <a href="http://bitcoin.org/bitcoin.pdf">bitcoin paper</a> suggests a method to discard old transactions. One should compute the Merkle Tree of the entire transaction history, and store only part of the tree.</p>

<p>However, I didn't notice this method implemented. <a href="https://github.com/bitcoin/bitcoin/blob/0f8cb5db73e8ab06b779b3cf82e26986ccc7c3f8/src/main.h#L919"><code>BuildMerkleTree</code></a> stores it in memory only, and seems to assume you're holding all transaction history, and the serialization method stores the <a href="https://github.com/bitcoin/bitcoin/blob/0f8cb5db73e8ab06b779b3cf82e26986ccc7c3f8/src/main.h#L1244">actual transactions</a> and does not store the Merkle Tree.</p>

<p>Is that implemented? Can you give me a reference to where is it in the code?</p>

<p>If not, is it planned for a specific future release?</p>

CC BY-SA 3.0
2012-02-20T11:36:31.157Z
bitcoin.org is where the standard client is hosted, but it's not generally used to refer to the client itself - it's usually called the standard client or the Satoshi client. AFAIK it does not currently implement pruning transactions.
Meni Rosenfeld
CC BY-SA 3.0
2012-02-20T11:41:55.737Z
@MeniRosenfeld Fixed, thanks. I'm not sure how exactly it should be done, and an implementation can make things clearer. Any calculation for how big a block will be with no pruning, in the next few years?
Elazar Leibovich
CC BY-SA 3.0
2012-02-20T12:58:58.153Z
I edited your question to include asking when is such a feature planned, hope you don't mind. (Also added a closing question mark to the title)
ripper234
CC BY-SA 3.0
2012-02-20T13:00:33.190Z
I was sure I had asked a similar question (about planning) in the past, but didn't find it now. I vaguely remmeber Gavin saying that "it's the next thing on the roadmap after multisig", but I don't have a citation, and I think it wasn't formalized anyway. For the cord, the straight answer to your question is "No, the current client does not prune history".
ripper234
CC BY-SA 3.0
2012-02-20T19:38:26.517Z
possible duplicate of [Is "Reclaiming Disk Space" already implemented? How effective will it be?](http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be)
Chris Moore
CC BY-SA 3.0
2012-02-20T19:39:37.730Z
See also the discussion and links in https://en.bitcoin.it/wiki/Thin_Client_Security
Chris Moore
<transactions><bitcoin-core><pruning><whitepaper>
Is pruning transaction history implemented in Satoshi's bitcoin client?
Elazar Leibovich
# Is pruning transaction history implemented in Satoshi's bitcoin client?

(Asked by: username_0 on 2012-02-20)

The original [bitcoin paper](http://bitcoin.org/bitcoin.pdf) suggests a method to discard old transactions. One should compute the Merkle Tree of the entire transaction history, and store only part of the tree.

However, I didn't notice this method implemented. [`BuildMerkleTree`](https://github.com/bitcoin/bitcoin/blob/0f8cb5db73e8ab06b779b3cf82e26986ccc7c3f8/src/main.h#L919) stores it in memory only, and seems to assume you're holding all transaction history, and the serialization method stores the [actual transactions](https://github.com/bitcoin/bitcoin/blob/0f8cb5db73e8ab06b779b3cf82e26986ccc7c3f8/src/main.h#L1244) and does not store the Merkle Tree.

Is that implemented? Can you give me a reference to where is it in the code?

If not, is it planned for a specific future release?

**Tags:** transactions, bitcoin-core, pruning, whitepaper

> **Comments:**
> **username_1**: bitcoin.org is where the standard client is hosted, but it's not generally used to refer to the client itself - it's usually called the standard client or the Satoshi client. AFAIK it does not currently implement pruning transactions.  
> **username_0**: @username_1 Fixed, thanks. I'm not sure how exactly it should be done, and an implementation can make things clearer. Any calculation for how big a block will be with no pruning, in the next few years?  
> **username_2**: I edited your question to include asking when is such a feature planned, hope you don't mind. (Also added a closing question mark to the title)  
> **username_2**: I was sure I had asked a similar question (about planning) in the past, but didn't find it now. I vaguely remmeber Gavin saying that "it's the next thing on the roadmap after multisig", but I don't have a citation, and I think it wasn't formalized anyway. For the cord, the straight answer to your question is "No, the current client does not prune history".  
> **username_3**: possible duplicate of [Is "Reclaiming Disk Space" already implemented? How effective will it be?](http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be)  
> **username_3**: See also the discussion and links in https://en.bitcoin.it/wiki/Thin_Client_Security  

---

## 4 answers

### Answer by username_4 on 2017-04-24. Score: 3

Since Bitcoin Core v0.8.0, the validation database ("chainstate" or "UTXO set", or "account balance sheet") is separated from the blockchain. When a new block comes in, its effects (removing spent inputs, and adding outputs) are applied to the database. This means blocks are still downloaded and verified like before, but they aren't used for validation anymore afterwards. Blocks are still stored on disk in order to send them to other nodes that are synchronizing, or to rescan for old transactions.

Since Bitcoin Core v0.11.0, it is also possible to run in a true pruned mode, where the blocks on disk are actually deleted after a while. Since v0.12 it is possible to use the wallet while running in pruning mode. Since v0.14 it is possible to manually prune (by issuing an RPC command rather than have the application decide).

Note that neither of these mechanisms rely on the mechanism described in the Bitcoin whitepaper.

> **Comments:**
> **username_5**: Related: https://bitcoin.stackexchange.com/questions/37496/how-can-i-run-bitcoind-in-pruning-mode  

---

### Answer by username_6 on 2012-04-20. Score: 1

I would assume this is not implemented because of the problem that username_4 mentioned. Having a client that only stores a pruned version of the block chain can't be friendly to other clients that don't have this pruning feature implemented since it won't be able to retrieve the original block chain.

Since a variety of clients are still undergoing development allowing alternative clients the choice of how to handle their block chain data allows for new innovations. For instance, it allows analysis of how Bitcoin has behaved over time. Even if you have not recorded this from the start.


---

### Answer by username_7 on 2015-03-02. Score: 0

Here are two options.
The first can be blockchain pool which will be torrent like storage and can be implemented independently in wallets (today's 30GB spread to 2000 clients with 50% redundancy will cause only 30MB size)

Second could be some kind of defragmentation, where is needed development of protocol. Here will be no problem to add block on the top of blockchain which includes let say 100k oldest blocks as a copy, without zero balance accounts. Question is only if here will be significant rate of defragmentation.
assumptions

* we do not need transactions which creates empty accounts (all was sent)
* we do not need transactions which do not change balance (all was sent back)
* we can set some time limit to dead accounts (only one transaction topped ou account and account never been used)

It is not simple solution and inactive account can not be refreshed until they are not running, then the last item is not quite safe.


---

### Answer by username_8 on 2012-03-30. Score: -4

No, it requires the entire history to verify new transactions (due to how the security of a new block in the chain requires the security of all previous blocks).

Some future client may not require the whole chain and not fully verify transactions, however I would not consider these secure for large transactions because I have no clue if the "skinny client" I'm on is not stuck on a malicious fork in the chain designed to allow double spends and someone has not ran off to Mexico with my Bitcoins.

> **Comments:**
> **username_4**: This is not correct. You do not need the entire history to verify transactions - spent and well-buried transactions could safely be removed if it were implemented. With the current network protocol, such a pruned node is not able to provide the block chain to other full nodes, however.  

---

