Optimise BitcoinSerialiser for Transactions. When calculating checksum on deserialize use it prepopulate the transaction's hash. Likewise on serialize check if the Transaction already has a hash and use that to write checksum bytes. This yields performance improvesment up to 400% by saving on a double hash.
Don't parse all the subcomponents of a Transaction purely to calculate its length, instead do the minimal work possible.
Recaching on a call to bitcoinSerialise(). Prevents double serialization of transactions and inputs/outputs when calculating a merkleroot during block serialization. Also makes it more likely the original larger byte array can be GC'd
1) Added getters and setters to many objects that lacked them.
2) Introduce a parseLite method that is called even in "lazy parse" mode. This calculates the length of the message so children can be skipped when parsing a container object.
3) Full serialization for AddressMessage
4) Added a (huge, standalone) SpeedTest.
5) Add unit tests for the matrix of lazy parsing modes.
A bunch of review comments are added to the TODO list for completion after the patch series is checked in. This is to avoid large numbers of merge conflicts as later parts of the patch-series are committed.
Don't deserialize block or tx messages that were already seen, to avoid wasting battery and causing memory spikes that can trigger OOM conditions. Updates issue 73.
1) Receiving coins regressed after the last optimization. Resolves issue 49.
2) Reorg handling expected to be able to connect all inputs.
Also other minor fixes and small additions.
Note that the endianness of the hashes is still very ad-hoc and messy. Next step is to pick an endianness and stick with it, to reduce the number of times reverseBytes is used.
- Extract serialization code out of NetworkConnection into a new class
- Created classes for Ping and VerAck messages
- Use reflection to create new message classes
- Add a few test cases to exercise the BitcoinSerializer class
Patch by Noa Resare.
On a MacBook pro with this store, the chain can be downloaded at about 2000 blocks per second. Difficulty transitions are not optimized but take around 50 msec. On a Google Nexus S the chain can be downloaded (via wifi) at 200 blocks per second and difficulty traversals take 2 seconds. At this time the profiles on both devices are dominated by verification costs, not storage.
- Split the unit tests for this into a separate file
- Add more tests for double spends, reversal of external spends and more edge cases
- Handle the case where transactions should be resurrected after a re-org
- Handle the case where transactions are overridden by double spends
Should address [some of] the points Miron raised during his review. There are likely still bugs but it's a lot closer to correct than before.
Activated the disabled tests in testForking, added a bunch more tests for this functionality.
Added various utility methods and made small fixes as required.
This changes the wallet format and invalidates existing wallets.
