Just to give you guys some numbers.
My current "ultraprune" branch (which, as Mike noted, currently doesn't prune at all) is mostly a rewrite of the block validation logic, which is faster than the current one, needs less storage, and supports block pruning. It also contains work done by Mike, which switches the database backend from BDB to LevelDB (which should give a nice speed improvement as well, in particular on slow storage).
In idealized laboratory conditions, I was able to make this branch synchronize from scratch in around half an hour on my laptop. Real life use will not reach such speeds (for now, there are other improvements possible that'll take us closer), but a full chain sync over network (mine was from a local disk) should be doable in a few hours.
To get an idea of the actual storage requirements (after pruning, which isn't done):
- Around 30 MB (right now) for the block chain index. This will grow linearly over time.
- Around 120 MB for the coin database. This grows +- following the green line in the graph below, +10% to +20%
- The actual block data: the size of the blocks themselves, as many as you can manage to keep.
- "block undo" data: this is specific to ultraprune's design, and requires around 1/9th of the size of the kept blocks
Here's a graph showing the size of the coin database (set of unspent transaction outputs), with and without pruning (note that the unpruned version of this isn't particularly useful - it's just there for comparison), and after removing several sizes of small/tiny outputs. The green line is the only actually meaningful one.
