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.
The help message for the address series of endpoints was optimistic
and not all documented ones have been implemented yet.
This removes the unimplemented ones to avoid confusion for users
reading this online.
I needed to update this auto test which used coins last moved in 2012 as
reference, but the test broke because the dusters (sending 547sats)
ended up adding a UTXO to the output.
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.
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.
TomZ