i can happily start testing this this weekend. however i'm not 100% sure how to get a copy. i looked around github, but wasn't sure which was the proper project. could i get a link and a simple "do this, this and this"? thanks. i feel like a newb. ugh. Arklan ---------- As long as there is light, the darkness holds no fear. And yet, even in the deepest black, there is life. - Arklan Uth Oslin I want to leave this world the same way I came into it: backwards and on fire. - Arklan Uth Oslin On Sat, Oct 20, 2012 at 4:33 PM, Pieter Wuille wrote: > Hello everyone, > > I've just merged my "ultraprune" branch into mainline (including > Mike's LevelDB work). This is a very significant change, and all > testing is certainly welcome. As a result of this, many pull requests > probably don't apply cleanly anymore. If you need help rebasing them > on the new structure, ask me. > > The idea behind ultraprune is to use an ultra-pruned copy (only > unspent transaction outputs in a custom compact format) of the block > chain for validation (as opposed to a transaction index into the block > chain). It still keeps all blocks around for serving them to other > nodes, for rescanning, and for reorganisations. As such, it is still a > full node. So, despite the name, it does not implement any actual > pruning yet, though pruning would be trivial to implement now. This > would have profound effects on the network though, so may still need > some discussion first. > > A small summary of the changes: > * Instead of blk000?.dat, we have blocks/blk000??.dat files of max > 128 MiB, pre-allocated per 16 MiB > * Instead of a Berklely DB blkindex.dat, we have a LevelDB directory > blktree/. This only contains a block index, no transaction index. > * A new LevelDB directory coins/, which contains data about the > current unspent transaction output set. > * New files blocks/rev000??.dat contain undo data for blocks > (necessary for reorganisation). > * More information is kept about blocks and block files, so > facilitate pruning in the future, and to prepare for a headers-first > mode. > * Two new RPC calls are added: gettxout and gettxoutsetinfo. > > The most noticeable change should be performance: LevelDB deals much > better with slow I/O than BDB does, and the working set size for > validation is an order of magnitude smaller. In the longer run, I > think it is an evolution towards separation between validation nodes > and archive nodes, which is needed in my opinion. > > -- > Pieter > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >