To send out transactions in the p2p net is quite a lot of work,
you need to find multiple peers to send the transaction to. First
you send an INV, then you respond to a getData to actually send
the transaction and last you wait for 'reject' messages that may
indicate that there is something wrong with the transaction.
This introduces the BroadcastTxData class that wraps a transaction
and gets callbacks for sending and for rejects, abstracting away
all the complexity for the user.
The uint256 and CKeyID classes are the same baseclass with template
differences only, which makes them fragile to use for overloading.
As such rename the convenience overload slightly.
The usage of byte-array in json is not well defined, and as such Qt just
no longer handles it as it could end up causing out-of-bounds issues.
This misuse is limited to our unit test, so this is a cheap update.
Ref; https://bugreports.qt.io/browse/QTBUG-84739
Instead of using open(), which makes unavailable the normal method,
use a new methodname instead.
This issue is a bit of an anti-pattern and it would likely be beneficial
to avoid having this as a subclass at all.
Based on the idea that randomly selecting a peer from our database will
prioritize based on the peers punishment score, this sets the punishment
for never connected-to peers at 10 (out of 1000) just to give a minor
benefit to speeding up the meshing.
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.
This fixes that the .info file is sometimes not written when nothing
changed in the db file.
This fixes that the info file with .1.info extension is reused again
and again, effectively reducing the usefulness of the snapshots.
This only really affects the indexer as pruning avoids this most
of the time.
Closes issue flowee-issues#6
this adds a listener interface and a way to emit the callbacks on
changing of the filter.
This also adds a mutex since we expect the Peer to use the filter which
will likely live in its own thread.
This makes the class thread safe and re-entrant.
Notice that we use a recursive mutex to allow various usecase on
altering the bloom filter.
The most involved one is a complete replacement which calls clear and
then various calls to add() style methods.
Second is a single 'add' which can be done without the clear first.
The second needs an explicit lock in the add() methods, which would
deadlock in the first usecase if I didn't pick the recursive mutex.
Instead of forwarding one transaction at a time as the peer sends them
to us, bundle them in a group of transactions known to be merkle-checked
and all belonging together in one block.
Since the peer has no obligation (and with CTOR even less) to send the
transactions in natural order, we should get them per block so we know
all transactions forwarded have parents.
This helps when SPV wallets are still behind on merkle-blocks while the
wallet shut down.
We start instantly again, instead of waiting for the first block to be
mined.
As the compile may or may not link to GMP, using projects
need to link to this too. Dynamic libs handle this, we ship
static libs and thus we need to handle this ourselves.
This avoids a peer once sending acceptable headers and never
being bothered again. Instead we now check regularly and keep
track of when the peer was known to follow the same chain as us.
The asio stuff is quite broken when it comes to, ironically,
concurrency.
Connecting to peers lead to lots of 'canceled' (sic) errors being
generated internally in asio and other such issues.
Even though they were called on separate objects.
Adding a mutex around the async_connect calls made the amount of
failures go down dramatically.
This patch also includes upgrading boost::mutex to the std-lib
versions.
TomZ