I got some UTXOs to test and now got some blocks filled
there, which proves the concept.
Its a bit slow to start (1 -> 20 tx are hardcoded) which was not an
issue if you can call generate() to mine, may be useful to adjust
for scalenet.
Yet, the basis works.
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 adds lots of little things;
* Add GetTransaction API call
* I refactored the GetBlock API a little to reuse code.
* a new 'Version' API call for the hub
* API for the logging manager, so we can set a default
setup with just C++-APIs
* various (usability) fixes in the FloweeServiceApplication
* Binding to localhost attempts to bind to both IPv4 and v6
* Print the actual transaction hex from indexer-cli (which really
is just a testing app)
Make things more foolproof by having similar items in different namespaces
use the same number.
Remove APIs for the wallet as that is not a shipped component of the Hub
The txVulcano wallet is currently really not fast,
so this code made the first mistake of network programming;
a big task was handled blocking the network handling.
The workerthread eventqueue is now used for this.
As we don't intent to have a perfect wallet on this side, the
transactions failing to validate on the Node is a direct effect and
expected and Ok. As such the client is now more tolerant.
This is a partial app which has as goal to generate transactions
and fill up blocks. A needed tool to test bigger blocks.
Secondairy goal is to test the Hub APIs in actual production
setting.
tomFlowee
TomZ