13

The original bitcoin paper 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 stores it in memory only, and seems to assume you're holding all transaction history, and the serialization method stores the actual transactions 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?

Improve this question
  • 2
    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 Feb 20 '12 at 11:36
  • @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 Feb 20 '12 at 11:41
  • 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 Feb 20 '12 at 12:58
  • 1
    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 Feb 20 '12 at 13:00
  • possible duplicate of Is "Reclaiming Disk Space" already implemented? How effective will it be? – Chris Moore Feb 20 '12 at 19:38
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.

Improve this answer
1

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.

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.

Improve this answer
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.

Improve this answer
-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.

Improve this answer
  • 2
    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 Mar 31 '12 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.