Instead of building a full copy of a CTransaction being signed, and
then modifying bits and pieces until its fits the form necessary
for computing the signature hash, use a wrapper serializer that
only serializes the necessary bits on-the-fly.
This makes it easier to see which data is actually being hash,
reduces load on the heap, and also marginally improves performances
(around 3-4us/sigcheck here). The performance improvements are much
larger for large transactions, though.
The old implementation of SignatureHash is moved to a unit tests,
to test whether the old and new algorithm result in the same value
for randomly-constructed transactions.
This change moves test data into the binaries rather than reading them from
the disk at runtime.
Advantages:
- Tests become distributable
- Cross-compile friendly. Build on one machine and execute in an arbitrary
location on another.
- Easier testing for backports. Users can verify that tests pass without having
to track down corresponding test data.
- More trustworthy test results and easier quality assurance as tests make
fewer assumptions about their environment.
- Tests could theoretically run at client/daemon startup and exit on failure.
Disadvantages:
- Required 'hexdump' build-dependency. This is a standard bsd tool that should
be usable everywhere. It is likely already installed on all build-machines.
- Tests can no longer be fudged after build by altering test-data.
libleveldb.a and libmemenv.a should be able to build in parallel, but in
practice calling the leveldb makefile ends up rewriting build_config.mk. If
one target tries to build while the other is halfway through writing the
.mk, the make ends up in an undefined state.
Fix that by making one depend on the other. This also reorders the variables
to be passed by param rather than via the environment, and combines the targets
into a single rule to avoid needless duplication.
As we'd previously learned, OSX's fsync is a data eating lie.
Since 0.8.4 we're still getting some reports of disk corruption on
OSX but now all of it looks like the block files have gotten out of
sync with the database. It turns out that we were still using fsync()
on the block files, so this isn't surprising.
Pieter Wuille