Calculates a hash to accelerate key import.
Enables skipping EC_KEY_check_key when a hash is present.
Benchmarks show 0.15ms per key vs 1.5ms per key.
An order of magnitude improvement.
Calculates a hash to accelerate key import.
Enables skipping EC_KEY_check_key when a hash is present.
Benchmarks show 0.15ms per key vs 1.5ms per key.
An order of magnitude improvement.
backwards compatible with previous wallet.dat format
Cool. This is interesting because on a wallet with lots of keys the initial startup is shockingly slow.
Please add a comment to the "key" / "wkey" case statement that explains the old/new data schema. Maybe:
// Old wallets store keys as "key"[pubkey] => [privkey]
// ... which was slow for wallets with lots of keys, because the public key is re-derived from the private key
// using EC operations as a checksum.
// Newer wallets store keys as "key"[pubkey] => [privkey][hash(pubkey,privkey)], which is much faster while
// remaining backwards-compatible.
@gavinandresen comment added
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/bc68788317a4ece16f0cfb0cb7eb1e0e220cbc6f for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
ACK. Tested loading old wallets with the new code, and loading new wallets with the old code, all was good.