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 explicitly detects the initial sync and refuses to create
any indexes on the SQL databases during this massive insert stage.
Some other minor issues got fixed here too.
where the UTXO allows you to find an output based on txid+output, the
spentoutput DB turns that around and allows you to find an input that
spends a certain output.
This also fits perfectly find into the UTXO database class, so this
creates a new dir "spent" which is filled as expected.
This adds all the header ints to chunked messages, solving the problem
of losing RequestId on roundtrips if the answer was too big.
Added a unit test for this "new" features.
This makes callbacks all use shared_from_this() in order to avoid
callbacks being done on deleted instances (thanks boost!).
Last, special case when the user doesn't connect but just sends messages
which caused a send of data, only to realize the connection wasn't open,
and then a connect.
This makes sure we immediately start a connect on queue of a message.
TomZ