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