This affects both the BlockChain/GetBlockHeaderReply and the
BlockChain/GetBlockVerboseReply calls.
The field with id 75 was confusingly called 'bits', but this is really
the blocktarget from the blockheaders. We renamed this.
This field is a int-encoded-floating point value and as such it makes no
sense to send it as a simple int. It is now a byte-array.
Notice that the documentation always listed it as a byte-array so we
actually fixed the implementation to follow the spec.
This test tests the new Mining::SubmitBlock feature.
We also test the GetBlock with the new FilterOnScriptType feature.
Some new helper methods in the messageBuilder and FastBlock are also
used and tested.
The API call for GetBlock has a filter-on-address functionality which is
now ported to no longer use ripe160 addresses but instead uses output-
script hashes.
This avoids problems for transactions not using p2pkh and generally is a
cleaner solution.
This also adds a unit test to test this feature.
The usage of a ripe160 for bitcoin addresses in the API and in the
Indexer loses some info, specifically what kind of script it is.
Additionally not all types of scripts fit this mold. At best that means
its not future-proof.
This adds a method to the API in order to select from a Tx the hashed
outscript (thats singlehashed sha256) and refactor the address indexer
to use that instead of the ripe160 address.
The API enums broke a little, so I used the opportunity to break it a
lot and clean up the enums in order to make them more future-proof.
But, yeah, software from before this commit is protocol incompatible
with software after this commit.
This also includes a little blockchain of 114 blocks (the first 100 just
coinbase to reach coin-maturity) with transactions generated by the
txVulcano. So lots of outputs.
I adjusted the BlackBoxTest to load this data into any hub with ease.
tomFlowee
TomZ