<p>AFAIK, all the transaction outputs are purged from the database when they are spent. Not from the bock database, though, but it just does not make too much sense to remove it from the block database, since it would only worsen the node's performance.</p>

<p>And you cannot purge unspent outputs, now matter how old they are, for quite an obvious reasons.</p>

CC BY-SA 3.0
2013-05-24T15:16:33.360Z
I think you might be misunderstanding the question. It _does_ make sense to remove some/all transactions from the client's copy of the blockchain (i.e. "block database") as it would save a lot of disk space for the clients. The protocol specifically allows for these partially purged clients (SPV clients), that's why the protocol uses a merkle root of the transactions and not a simple list of the transactions. But SPV isn't part of the standard client at this time and this question is really about why that doesn't seem to be a priority.
David Ogren
CC BY-SA 3.0
2013-05-24T15:36:47.693Z
Well, considering that the entire blockchain is now barely 8GB, we obviously have a different understanding of what _a lot of disk space_ is.
Moreover, if you remove transactions from your database, you won't be able to serve blocks anymore, so you won't be able to act as an actual node.
Gigi
CC BY-SA 3.0
2013-05-24T15:59:37.493Z
That 8GB isn't a lot of block space for current desktops and laptops might not be a bad answer. (I somewhat agree with that. Although it's really the downloading and verifying that seems to cause the most issues, not the disk space itself.) My comment was more that your answer was addressing something not asked, i.e. purging from the lookup databases when the question was pretty specifically about the blockchain itself and SPV clients. (Also, someone who uses a laptop with a single 128GB SSD might disagree with your assessment that 8GB isn't a lot.)
David Ogren
CC BY-SA 3.0
2013-05-24T16:01:03.047Z
Oh, I thought SPV clients are even just interested in the headers and _their_ transactions, opposed to a pruning node which has all unspent transactions.
Borph
CC BY-SA 3.0
2013-05-24T16:03:01.367Z
@Gigi: yes, when you throw away old spent transaction, the world would forget about them when really **all** nodes behave like this. But what is considered to be "unable to act as a node"?
Borph
CC BY-SA 3.0
2013-05-24T16:05:15.500Z
At least to my understanding, SPV just means that the client can request transaction details "on demand" rather than downloading and verifying them all upfront. An SPV client might just keep their own transactions, but they really could keep any subset.
David Ogren
CC BY-SA 3.0
2013-05-24T17:38:45.937Z
@Borph, by "unable to act as a node" I meant that the main feature of a bitcoin node is serving blocks for the P2P network - full blocks, and all of them, starting from #1. I understand that in theory you can serve only partial blocks (thus skipping the spent transaction), but the problem is that the current protocol does not support it. And if you want to change the protocol and then make sure that all the nodes are upgraded, before you start serving them only partial blocks... well that will surely take awhile; june 2025 would be my rough estimate :)
Gigi
CC BY-SA 3.0
2013-05-24T15:05:56.307Z
2013-05-24T15:05:56.307Z
Gigi
<p>Pruning is being considered, in fact, it was taken into account when designing the 0.8 database format. The unspent transaction outputs (which is the only essential piece of data necessary for validation) are already kept in a separate database, so technically removing old blocks is perfectly possible. It'll likely require some small changes to make sure the code doesn't break when block data that doesn't exist anymore is requested, but this is easy.</p>

<p>The reason it's not implemented is because of the effect on the network as a whole. If a large amount of nodes starts pruning old block data away, it will become harder for new nodes starting up to find the historic data to verify. This is not a problem as such - I expect enough copies will remain that this is not a true problem - but we need a discovery mechanism so nodes don't need to arbitrarily try peers until they happen to reach one that has the blocks they need. In fact, there's a <a href="http://thread.gmane.org/gmane.comp.bitcoin.devel/2065" rel="nofollow">discussion</a> going on on the bitcoin-development mailing list about this right.</p>

<p>EDIT: Pruning was implemented in Bitcoin Core 0.11, and is fully functional since 0.12.</p>

CC BY-SA 3.0
2013-05-31T08:53:07.247Z
So the current problem to solve is on the network level! Nodes have find nodes - with certain information! DHT sound very promising to me to solve this.
Borph
CC BY-SA 3.0
2013-05-31T08:56:56.120Z
Extra question: Imagine we really would loose the historic data. Would it stop Bitcoin? Or would be a, hum, "consensus on the assets, although we don't know how we came here".
Borph
CC BY-SA 3.0
2015-03-26T17:29:09.687Z
Presumable, nodes offering full history would be more expensive to maintain than nodes that have been pruned. What is the incentive for anyone to run nodes with full history?
snapfractalpop
CC BY-SA 3.0
2015-06-25T08:58:06.623Z
What is the incentive to make anyone's full node accessible to others at all?
Pieter Wuille
CC BY-SA 3.0
2013-05-24T18:13:07.603Z
2016-06-20T19:52:46.227Z
2016-06-20T19:52:46.227Z
Pieter Wuille
<p>I understand that Bitcoin scales in several meanings (<a href="https://en.bitcoin.it/wiki/Scalability" rel="nofollow noreferrer" title="Scalability">Scalability</a>), and pruning is one important concept of it (<a href="https://bitcoin.stackexchange.com/questions/10333/blockchain-long-run-issue/10334#10334">SE Question</a>). I also understand that a "Simplified Payment Verification" (SPV) needs to trust a lot the peer he is obtaining the block chain from.</p>

<p>A very conservative pruning (e.g. transactions older than six month and spent) wouldn't do much harm, especially when it would be only a configuration option for bitcoin-qt. That way the default is the full node, but it's easy to have a "small node".</p>

<p>But I don't see it coming anyhow soon. Is there a reason? Is it so important to have full nodes at the moment that the devs say "either you go for all or nothing"? Or is the development effort the bottleneck? IMHO a large network of non-SPV nodes is more important than a small network of full nodes.</p>

<p>Edit: Let's put it more concrete: Is there a major security issue of <strong>not</strong> having the complete transaction history of the world back to the genesis block?</p>

<network><nodes><pruning>
Why is pruning not considered already at the moment?
Borph
# Why is pruning not considered already at the moment?

(Asked by: username_0 on 2013-05-24)

I understand that Bitcoin scales in several meanings ([Scalability](https://en.bitcoin.it/wiki/Scalability "Scalability")), and pruning is one important concept of it ([SE Question](https://bitcoin.stackexchange.com/questions/10333/blockchain-long-run-issue/10334#10334)). I also understand that a "Simplified Payment Verification" (SPV) needs to trust a lot the peer he is obtaining the block chain from.

A very conservative pruning (e.g. transactions older than six month and spent) wouldn't do much harm, especially when it would be only a configuration option for bitcoin-qt. That way the default is the full node, but it's easy to have a "small node".

But I don't see it coming anyhow soon. Is there a reason? Is it so important to have full nodes at the moment that the devs say "either you go for all or nothing"? Or is the development effort the bottleneck? IMHO a large network of non-SPV nodes is more important than a small network of full nodes.

Edit: Let's put it more concrete: Is there a major security issue of **not** having the complete transaction history of the world back to the genesis block?

**Tags:** network, nodes, pruning


---

## 2 answers

### Answer by username_3 on 2013-05-24. Score: 12 | Accepted answer

Pruning is being considered, in fact, it was taken into account when designing the 0.8 database format. The unspent transaction outputs (which is the only essential piece of data necessary for validation) are already kept in a separate database, so technically removing old blocks is perfectly possible. It'll likely require some small changes to make sure the code doesn't break when block data that doesn't exist anymore is requested, but this is easy.

The reason it's not implemented is because of the effect on the network as a whole. If a large amount of nodes starts pruning old block data away, it will become harder for new nodes starting up to find the historic data to verify. This is not a problem as such - I expect enough copies will remain that this is not a true problem - but we need a discovery mechanism so nodes don't need to arbitrarily try peers until they happen to reach one that has the blocks they need. In fact, there's a [discussion](http://thread.gmane.org/gmane.comp.bitcoin.devel/2065) going on on the bitcoin-development mailing list about this right.

EDIT: Pruning was implemented in Bitcoin Core 0.11, and is fully functional since 0.12.

> **Comments:**
> **username_0**: So the current problem to solve is on the network level! Nodes have find nodes - with certain information! DHT sound very promising to me to solve this.  
> **username_0**: Extra question: Imagine we really would loose the historic data. Would it stop Bitcoin? Or would be a, hum, "consensus on the assets, although we don't know how we came here".  
> **username_4**: Presumable, nodes offering full history would be more expensive to maintain than nodes that have been pruned. What is the incentive for anyone to run nodes with full history?  
> **username_3**: What is the incentive to make anyone's full node accessible to others at all?  

---

### Answer by username_1 on 2013-05-24. Score: -1

AFAIK, all the transaction outputs are purged from the database when they are spent. Not from the bock database, though, but it just does not make too much sense to remove it from the block database, since it would only worsen the node's performance.

And you cannot purge unspent outputs, now matter how old they are, for quite an obvious reasons.

> **Comments:**
> **username_2**: I think you might be misunderstanding the question. It _does_ make sense to remove some/all transactions from the client's copy of the blockchain (i.e. "block database") as it would save a lot of disk space for the clients. The protocol specifically allows for these partially purged clients (SPV clients), that's why the protocol uses a merkle root of the transactions and not a simple list of the transactions. But SPV isn't part of the standard client at this time and this question is really about why that doesn't seem to be a priority.  
> **username_1**: Well, considering that the entire blockchain is now barely 8GB, we obviously have a different understanding of what _a lot of disk space_ is. Moreover, if you remove transactions from your database, you won't be able to serve blocks anymore, so you won't be able to act as an actual node.  
> **username_2**: That 8GB isn't a lot of block space for current desktops and laptops might not be a bad answer. (I somewhat agree with that. Although it's really the downloading and verifying that seems to cause the most issues, not the disk space itself.) My comment was more that your answer was addressing something not asked, i.e. purging from the lookup databases when the question was pretty specifically about the blockchain itself and SPV clients. (Also, someone who uses a laptop with a single 128GB SSD might disagree with your assessment that 8GB isn't a lot.)  
> **username_0**: Oh, I thought SPV clients are even just interested in the headers and _their_ transactions, opposed to a pruning node which has all unspent transactions.  
> **username_0**: @username_1: yes, when you throw away old spent transaction, the world would forget about them when really **all** nodes behave like this. But what is considered to be "unable to act as a node"?  
> **username_2**: At least to my understanding, SPV just means that the client can request transaction details "on demand" rather than downloading and verifying them all upfront. An SPV client might just keep their own transactions, but they really could keep any subset.  
> **username_1**: @username_0, by "unable to act as a node" I meant that the main feature of a bitcoin node is serving blocks for the P2P network - full blocks, and all of them, starting from #1. I understand that in theory you can serve only partial blocks (thus skipping the spent transaction), but the problem is that the current protocol does not support it. And if you want to change the protocol and then make sure that all the nodes are upgraded, before you start serving them only partial blocks... well that will surely take awhile; june 2025 would be my rough estimate :)  

---

