Hello all,
I've uploaded a new set of builds of bitcoind/Bitcoin-Qt to my
builds page. The new "turbo" build is based on current master on git, plus some more experimental patches (Hal Finney's
optimized secp256k1 code, and parallel script verification). The source code for these can be found
here (.tgz archive
here).
Disclaimer: don't use these for any serious stuff - I am not responsible for destroyed wallets or exploded CPU's.
Testing of these is very welcome.
As the most invasive change is in the block/transaction validation system, this is the most interesting part to test. I am very interested in reports about speed, CPU usage, memory usage, ... during initial block synchronization, in particular on Windows systems. Obviously, crashes or other unexpected behaviour is even more important.
As these builds use the new 0.8 database code ("ultraprune", as I called it before), they will not use the existing block files/database from 0.7.2 or earlier. There are several ways to import the data:
- Put bootstrap.dat in your data directory.
- Start the program with options -loadblock=path/to/old/blk0001.dat -loadblock=path/to/old/blk0002.dat.
- If you already have a full 0.8 database (perhaps from a next-test build), you can use the new -reindex option to rebuild your index from scratch, redoing the block validation process, reusing the block data you already have on disk.
- Obviously, you can also just let it synchronize from network, but as the current block-fetch logic is somewhat of a hack, you may get unlucky, and hit a slow peer, or have downloads that stop for long periods of time. It is advised to use -connect=IP to connect to a single fast peer (you can use my server, 178.18.90.41, for this purpose if needed) for that.
As these builds use parallel script verification (only enabled after block 193000, the last checkpoint), you may wish to control how many threads are used (don't use more than the number of CPU cores you have). By default, it will try to autodetect, but you can use the
-par=N option to select the number of threads. One interesting thing you can test is comparing
-par=1 with higher numbers, and check the speedup (in particular of the blocks after 193000).
Other options which may be useful to play with:
- -dbcache=N tweaks the amount of cache used. N is a number in megabytes (default is 25), but higher numbers may result in significant speedups.
- -logtimestamps adds timestamps to the output in the debug.log file, which may be very useful to compare speed.
- -benchmark produces detailed timing information during block validation (not very accurate on Windows, unfortunately).