This new flag to the getBlock API call allows us to select
a transaction based on the usage of a certain script opcode.
This uses the new metadata index.
This adds an option to the GetTransaction Flowee API to return the fees
for a whole transaction.
Support for this is added in the Blockchain (searcher) and the
RestService components.
Notice that no fees will be returned if the BlockMetaData was not
created properly.
This introduces several options for public node operators to limit their
nodes usage by 3rd parties, this is aimed at usage of resource-hungry
areas.
We allow limiting the amount of connections any single IP can keep open
with us.
We limit the amount of reconnects we allow in a short number of seconds.
We allow limiting the number of addresses (or scriptHashes) a peer can
register for the node to scan.
The last one is for both the addressMonitorService as well as for the
getBlock filters.
For node operators these items become available using command line
options or config-file options. By default these limits are unlimited as
we assume default usage to be private.
We calculate the needed space for the network buffers before we fill them,
as new features are added guestimating ended up short.
Lets do the real calculation.
When the transaction offset is wrong and doesn't parse we turn the
generic runtime_exception into one that goes back to the API caller.
Also catch those generic exceptions on the server level to avoid this
kind of error from disconnecting a peer.
This implements the sendTransaction command using the async framework,
allowing clients to benefit from multi-core systems to process
transactions in parallel when being submitted to the Hub.
The current design of the API is that all questions are answered in-
order. This implies that handling of one connection will also just use
one thread.
If we want to improve performance of things like "sendTransaction" we
want an async option, which runs the action and generates the answer
when its done in a separate thread (a new one for each async-request).
This breaks the in-order reply sequence for clients and as such it
requires them to set a new header-option to enable this.
When you request matching transactions from the mempool for certain
addreses, the API now returns the matched output-index as a separate
tag, which makes it easier to, for instance, use the 'amount' field in
the reply.
The mempool search now shares its serialization code with the blockchain
transaction fetcher, allowing all the filtering and include flags to work
here too.
This also fixes several bugs and reverts the mempool API change.
Additionally I return the FirstSeenTime for each mempool entry.
There is a slight API breakage in the LiveTransactions service, which as
far as I know is still unused outside of Flowee.
These enum values changed:
Api::LiveTransactions::
Transaction 20 => 25
UnspentState 23 => 26
OutputScript 24 => 23
The reason for this change is to have the Blockchain namespace in
sync with the LiveTransactions namespace for similar features.
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 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.
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.
tomFlowee
Justaphf