This is a feature request following the fact that some sysops use a
symlink for the unspent dir and don't want the reindex to delete the
symlink itself.
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.
This fixes the logic that finds out it should resume an interrupted
process. The code had false positives in case of a message split over
multiple TCP frames.
We connect to the "first" priority stated segments first, in order to
allow the UX to be made much better since it may take a bit of time to
find peers.
and update the definitions of the Mainnet, Testnet (v3), and Regtest chain params accordingly. The heights for all 3 chains were taken by verifying the values in both BU and BCHN code bases.
NOTE: For TestNet v3, there is a 1 block discrepancy between BU (1378461) and BCHN (1378460) for the height of the May 2020 hardfork. I arbitrarily selected the value from BCHN, I'm not sure which is correct.
To make sure that a pair of really large transactions being used
to create a DSP doesn't cause a blocking thread, this runs a
benchmark on a pair of transactions with 300 inputs each, causing
45k comparisons to be made.
On my laptop this results in 0.6 msecs for this creation of the DSP.
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.
* API docs
* Fix possible race condition in addOrphan()
* Reject proofs that violate simple constraints
* clear up possible confusing API (first/double spender getters).
This is written to be especially useful for packages since it will
create a log dir /usr/log/flowee/
and additionally it will log to stdout, which systemd / journald will
pick up.
TomZ