Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMd<div class="post">By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster. &nbsp;It downloads in about 30 minutes.<br/><br/>The database default had it writing each block to disk synchronously, which is not necessary. &nbsp;I changed the settings to let it cache the changes in memory and write them out in a batch. &nbsp;Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.<br/><br/>I only enabled this change during the initial block download. &nbsp;When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.<br/><br/>I built a test build if you'd like to start using it:<br/><br/><a href="http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip">http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip</a><br/><a href="http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz">http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz</a><br/><br/>These binaries also include Gavin Andresen's JSON-RPC HTTP authentication feature and the other important security improvements from 0.3.2.<br/><br/>I've been running a test over the last 24 hours that kills and restarts it randomly every 2-60 seconds (poor thing) while it's trying to do an initial block download and it's been fine.<br/><br/>There are no changes to the way it handles wallet.dat. &nbsp;This change is only for blk*.dat and the non-critical addr.dat. &nbsp;You can always delete blk*.dat if it gets screwed up and let it re-download.<br/></div> text/html