This supplies a push notification on txid becoming known to the Hub.
Additionally this changes its close relative the AddressMonitorService
to use a different tag for the transaction data and the
double-spend-proof data so as to make it obvious which one is being
sent.
From now on, make sure that the minor always has at least 2 digits
which allows us to use string compare of versions even if we have
more than 9 releases in a year.
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.
In the address monitor service this detects specifically if a double
spend detected by the Hub is applicable for our subscriber, and if it is
then a Message will be sent to the subscriber.
This introduces a new message type DoubleSpendFound
and changes the API for the TransactionFound message while dropping the
TransactionRejected message.
This is an overload of message() specifically meant to build
replies to incoming messages.
The behaviour changed here is that incoming messages with
headers other than "RequestId" now get copied to the outgoing
message by default.
This also includes a little blockchain of 114 blocks (the first 100 just
coinbase to reach coin-maturity) with transactions generated by the
txVulcano. So lots of outputs.
I adjusted the BlackBoxTest to load this data into any hub with ease.
The old algorithm could end up doubling the size every time it
ran out, which eventually consumes all memory.
This way we reset to the user-default size when useful and increase
only based on need.
This means that the programmer needs to make a better estimation on
maximum size of messages, but it avoids behavior similar to memory
leaks.
Double check our message-calculation is proper by checking the result.
Notice that asserts and logDebug both are turned off in release builds,
so this is just added to debug builds.
The command really only accepts IP addresses, but we use 'localhost' as
an exception to bind to loopback for ipv4 and ipv6 at the same time.
Also improve logging of errors and avoid failing to start the API
service if a bind address wasn't an IP.
Where we wrap the old RPC code we need to revert the byte-order from the
strings created there for the uint256.
This simplyfies the code by introducing a helper method.
The rule is that all sha256s are serialized like they are printed (so
zeros first for a blockID), this updates various places in the API did
reversed this order.
Also upgrade the cashier app with logging, ctrl-c catching
and debug + version command line arguments.
Last, this checks the server version and exits if the Hub
version is too old.
Also write some new accessor methods on the baseclass.
The longer term idea is to make the server itself only use the uint160
raw version for bitcoin addresses.
For now move the encodings (between that uint160 and human-readable) to
the utils library.
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)
The main goal of this is to make sure that network services
implementations don't reuse one bufferpool for all their remotes as that
can cause threading issues.
One bufferpool per remote is now made easy.