In most cases headers would be automatically downloaded if we didn't
connect to that peer for a while, but that is not a guarentee so lets
make sure we actually start downloading headers from any peer we can :)
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).
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 NetworkManager now has more mature flow-control which means that we
send our buffers more regularly and we delay parsing received data if the
sending takes too long.
The direct effect should be that creating of a large number of messages
in response to incoming messages is no longer a problem in many cases.
TomZ