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.
We used various ways to enable new features over the last 10 years.
We can remove that legacy code and just set the blockheight.
This cleans up the code quite a bit.
This makes the whitespace usage more in line with the standard.
This also moves an implementation of a virtual method to the cpp file
in order to avoid dynamic linking issues down the line.
This makes the service mostly self-documenting as it serves plain simple
html pages for error messages which show the end points you can use.
This adds support for the "unspent outputs for address" endpoint.
The very famous bitcore project presents an JSON based service which
presents blockchain data. This application aims to duplicate all the same
functionality but by using Flowee services instead.
The core APIs in Flowee are quite low-level and especially combining
results from multiple services becomes tedius, verbose and thus
error-prone.
For this reason I wrote a new SearchEngine and related classes which
allow one to create a single compound request, submit it to the engine and
get a callback when it is done.
For instance one can now create a request for a transaction by txid and the
system will split this into a txid-lookup and the actual fetch for the
transaction.
Enough callbacks and options exist to be able to add a lot more details
this way in a simple manner.
TomZ