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.
Remove addresses of type ripe160 to be used in the API of AddresMonitor
API service. Instead use a sha256 hash of the entire output script.
This is mostly internal changes not affecting the operations much.
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 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