The callback on each transaction was only called when individual tx
were fetched, which is "magic" behaviour and I don't like
inconsistencies.
So, also call the callback for each transaction in a block we fetched.
This will most likely benefit some FloweeJS users when they do some stuff
that I didn't think a good idea, at least this way they will not get
a bunch of errors :)
The FloweeJS component uses this class but requires the usage
of the NodeJS 'main' thread. Which needs safe access to the jobs
list at the same time the Flowee workers need access.
Simple solution; add a mutex.
Make the UTXO search callback actually useful for more than tests.
This passes all the data we have and what the user could want to use,
also updating the receiver (bitcore-proxy).
Make the callback happen after we get the indexer status.
Additionally, fix the issue where looking up a txid that failed
would end up being recursive due to us copying the initially requested
hash. Causing it to be a duplicate (which then fails etc).
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 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