@sipa, may i ask :
will UltraPrune survive from large reorg ?
Yes, barring implementation bugs it behaves just like a normal node externally. will UltraPrune survive from large reorg ?
Topic: Pruning - Is anyone working on its implementation? (Read 1718 times)
@sipa, may i ask :
will UltraPrune survive from large reorg ?
will UltraPrune survive from large reorg ?
Just my personal experience here in case any devs are interested.
I have given up regularly running a bitcoin node
I like to turn computers off at night or when I'm not using them much. It currently takes too long when I turn them on the next day to process all the last blocks, I'd rather be able to turn a computer on and then in a reasonable amount of time send and receive (confirm receipt of) coins.
I have given up regularly running a bitcoin node
I like to turn computers off at night or when I'm not using them much. It currently takes too long when I turn them on the next day to process all the last blocks, I'd rather be able to turn a computer on and then in a reasonable amount of time send and receive (confirm receipt of) coins.
Thanks for the report. We definitely hear you, and hope you will try 0.8. The network sync (processing blocks) is significantly faster, minutes instead of hours.
I don't suggest using an online wallet. Putting your money into somebody elses hands is risky.
+1000
The next Bitcoin release, 0.8, will be MUCH faster. That is the result of Pieters work. You may find you can run a node again when the next release is out.
I don't suggest using an online wallet. Putting your money into somebody elses hands is risky. A better solution is to use MultiBit. It has its faults, but it is much much faster than a regular Bitcoin node and still handles everything locally. It's beta-ish but getting better all the time.
I don't suggest using an online wallet. Putting your money into somebody elses hands is risky. A better solution is to use MultiBit. It has its faults, but it is much much faster than a regular Bitcoin node and still handles everything locally. It's beta-ish but getting better all the time.
Just my personal experience here in case any devs are interested.
I have given up regularly running a bitcoin node
I like to turn computers off at night or when I'm not using them much. It currently takes too long when I turn them on the next day to process all the last blocks, I'd rather be able to turn a computer on and then in a reasonable amount of time send and receive (confirm receipt of) coins.
Obviously, for these tasks an online wallet + offline storage is a better solution for me than running a node.
I'm not sure what this means for the network, but for me it is not the disk space that is the problem but the block verification time which causes the problem.
I have given up regularly running a bitcoin node
I like to turn computers off at night or when I'm not using them much. It currently takes too long when I turn them on the next day to process all the last blocks, I'd rather be able to turn a computer on and then in a reasonable amount of time send and receive (confirm receipt of) coins.
Obviously, for these tasks an online wallet + offline storage is a better solution for me than running a node.
I'm not sure what this means for the network, but for me it is not the disk space that is the problem but the block verification time which causes the problem.
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):
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.
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.
I still have more than 1TB left on volume where blockchain are located.
Verification against very big blockchain requires a lot of resources. Sometimes I notice lags using Bitcoin 0.7.0 on a computer with 4 cores of 3.2 GHz and 8 Gb RAM.
I still have more than 1TB left on volume where blockchain are located.
The full blockchain is required for miners and new nodes who want to download and verify the blockchain by themselves. OK, not so sure about miners because I have read they need the full blockchain but as I understand the miners can verify the transactions of unspent outputs from pruned blockchain too.
The full blockchain is required for miners and new nodes who want to download and verify the blockchain by themselves. OK, not so sure about miners because I have read they need the full blockchain but as I understand the miners can verify the transactions of unspent outputs from pruned blockchain too.
Actually deleting data needs careful thought and rollout to ensure there's always enough nodes with full copies of the block chain to bring up new nodes.
Full copy of the blockchain is required for limited amount of time. Until majority of nodes move to software with pruning. The others will be forced to do the same. Am I right?
Actually despite the name ultraprune does not prune. It lays the groundwork for pruning. Actually deleting data needs careful thought and rollout to ensure there's always enough nodes with full copies of the block chain to bring up new nodes.
Currently I'm merging in work by Matt Corrallo into bitcoinj that has an ultraprune like design, but does actually delete data. It'll be some time before I'd suggest anyone relies on such a node though.
Currently I'm merging in work by Matt Corrallo into bitcoinj that has an ultraprune like design, but does actually delete data. It'll be some time before I'd suggest anyone relies on such a node though.
Thank you. Looking forward to see it in real clients.
I read few topics about pruning here. It's supposed to help to keep the blockchain small. Any progress in this direction?
Jump to: