<p>A transaction consumes all of the coins for the connected transaction outputs.  But a bitcoin address can have multiple transactions.  So even though one transaction is consumed, that doesn't mean the address doesn't have any other coins.</p>

<p>Your general idea, though, is correct.  You can remove a transaction once all of its outputs have been spent (a transaction can have more than one output, so you have to track each output).  This has been discussed and even implemented in alternate bitcoin clients.  I don't know if or when it might be implemented in the reference client (bitcoind/bitcoin-qt).  </p>

<p>I have an implementation that I have been working on which uses a SQL database.  So far, it has processed the block chain up to August 2013 and there are 2,000,000 transactions with unspent outputs.  The database itself is around 1.2GB at the moment, so it is a significant saving over the full blockchain (15.1 GB on my system).  The drawback is you cannot supply the full blockchain to other nodes (I keep just the last 30 days).  So you would still need full nodes to provide the blockchain or download sites/torrents to allow a new node to get up to speed.</p>

CC BY-SA 3.0
2014-01-10T15:19:57.847Z
2014-01-10T15:19:57.847Z
ScripterRon
<p>After a lot of reasearch on the net, I still can figure out if the following idea is relevant or not :</p>

<p>I know (or at least I think I know) that each transaction consume all the bitcoins present at the inputs addresses. So if a bitcoin address is in the inputs of a transaction, you don't have to look at all the transactions older than this one to know how much bitcoins there is for this address. That means that we could remove all these olders transactions from the blocks keeping only there hashes via the Merkle pruning trick. With time, the Merkle Trees in each old blocks will become smaller and smaller so that space can be spared. </p>

<p>I understand that it will erase forever a part of the transactions, but the number of bitcoins for each bitcoin address will remain correct and perhaps that's the price to pay to keep a managable blockchain.</p>

<p>Is there already some work in this direction ?
Is this a stupid idea ?</p>

<p>Thank you for your help</p>

<transactions><blockchain><merkle-tree>
Old transactions in the blockchain
Sylvestre
# Old transactions in the blockchain

(Asked by: username_0 on 2014-01-10)

After a lot of reasearch on the net, I still can figure out if the following idea is relevant or not :

I know (or at least I think I know) that each transaction consume all the bitcoins present at the inputs addresses. So if a bitcoin address is in the inputs of a transaction, you don't have to look at all the transactions older than this one to know how much bitcoins there is for this address. That means that we could remove all these olders transactions from the blocks keeping only there hashes via the Merkle pruning trick. With time, the Merkle Trees in each old blocks will become smaller and smaller so that space can be spared.

I understand that it will erase forever a part of the transactions, but the number of bitcoins for each bitcoin address will remain correct and perhaps that's the price to pay to keep a managable blockchain.

Is there already some work in this direction ?
Is this a stupid idea ?

Thank you for your help

**Tags:** transactions, blockchain, merkle-tree


---

## 1 answers

### Answer by username_1 on 2014-01-10. Score: 1 | Accepted answer

A transaction consumes all of the coins for the connected transaction outputs. But a bitcoin address can have multiple transactions. So even though one transaction is consumed, that doesn't mean the address doesn't have any other coins.

Your general idea, though, is correct. You can remove a transaction once all of its outputs have been spent (a transaction can have more than one output, so you have to track each output). This has been discussed and even implemented in alternate bitcoin clients. I don't know if or when it might be implemented in the reference client (bitcoind/bitcoin-qt).

I have an implementation that I have been working on which uses a SQL database. So far, it has processed the block chain up to August 2013 and there are 2,000,000 transactions with unspent outputs. The database itself is around 1.2GB at the moment, so it is a significant saving over the full blockchain (15.1 GB on my system). The drawback is you cannot supply the full blockchain to other nodes (I keep just the last 30 days). So you would still need full nodes to provide the blockchain or download sites/torrents to allow a new node to get up to speed.


---

