Summary:
CMerkleBlock::CMerkleBlock called IsRelevantAndUpdate() on each transaction
in order, which (due to the outpoint-adding feature) assumes a topological
order of transactions in order to work correctly. If an outpoint of
interest were created later in a block than when gets spent, then it would
be added into the bloom filter too late, and thus that spending transaction
would get missed.
This changes CMerkleBlock::CMerkleBlock to scan all outputs first, then
make a second loop to scan all inputs. This requires breaking up the
IsRelevantAndUpdate() function into two parts. The original
IsRelevantAndUpdate() functionality remains fully intact however, as it
gets called from mempool-related code (mempool has topological order) and
tests.
Note that vMatchedTxn.push_back is moved into the second loop so that index
i keeps ascending order, in case that is somehow relevant. (the tests at
least do check this)
A two-loop construction like this will very slightly increase the false
positive rate.
Originally by: Mark Lundeberg
This adds a unit test to see if the combination of invalidateBlock and
reconsiderBlock do what we expect to do.
The main issue was that we store an invalidated block in the UTXO and we
forgot to re-validate that on reconsider.
Additionally I avoid writing a lot of unchanged data to the block-index.
We already had in place the blockSizeAcceptLimit as the limit
on messages, which is now the only limit.
In practice this means when the operator sets the maximum mining
size that we adjust the blockSizeAcceptLimit, if they only set the
blockSizeAcceptLimit, we use that (plus a margin) to limit messages
both on the p2p layer and on the RPC (JSON) layer we change the
limit to be twice the blockSizeAcceptLimit (copied those numbers
from BCHN).
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.
* API docs
* Fix possible race condition in addOrphan()
* Reject proofs that violate simple constraints
* clear up possible confusing API (first/double spender getters).
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.
Small refactor; move the partition check away from main and the obsolete
global variables we used to use, instead now just add it to the DB which
owns the data it works on.
This fixes the bug that in various cases we'd incorrectly get a warning
about no blocks being found in the last N hours.
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.
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
The NetworkManager usage was mostly for low connection counts and this
made defaults selection easy.
With more usages it is important to allow the NWM-connection to be more
configurable about memory usage and leaner in general.
This changes the headers-buffers (used to create envelopes) to not be per
connection anymore but per thread using the tread_local keyword.
This changes the ring-buffers to become configurable using
NetworkConnections::setMessageQueueSizes().
Also removing some include statements where they were not really needed
in the P2PNet lib.
This is part of the protocol upgrade for 2020-05-15, and in general it
seems to go the direction of "we did this before, lets do this again".
The spec is clear enough, but there is still a lack of questioning and
testing. The problem this attempts to fix has been neutered for years[1].
The spec states:
> The essential idea of SigChecks is to perform counting solely in the
> spending transaction, and count actual executed signature check
> operations.
This, however nobel and logical, ignores that the
check-for-being-too-costly just pulled in a UTXO lookup and the loading
of the output script from the historical chain.
The goal that we protect against CPU over-use may be reached, but the
price is a total system slowdown. You can have multiple CPUs, but the
bus to permanent storage has one, max 2 parallel pipes.
To ensure theHub stays the number one scalable node, I didn't blindly
follow the spec, while making sure that the Hub is correctly going to
follow/reject consensus violations of newly mined blocks.
As a result the implementation in Flowee the Hub:
* does not check sigcheck-counts on historical blocks (more than 1000
blocks in the past).
This may increase the risk of chain-splits ever so slightly, but the cost
of disk-IO would be too high.
* No longer stores the value in the mempool, nor uses it for the
CPU-miner.
* Ties the sigcheck-limits to the user-set block-size-accept-limit.
This is contrary to the spec which mistakenly thinks that BCH has a
max block-size in the consensus rules. The effect is the same, though.
* The per-intput standardness suggestion is not implemented because
standardness checks don't currently fetch the previous outputs and
that would be too expensive to add.
* Standardness rules for the whole transaction are moved to the
mempool-acceptance logic instead. The cost would be too great
otherwise, similar to the previous point.
Again, the effect is the same as likely intented.
---
1) since the intro of the CachingTransactionSignatureChecker
It was only called twice, and in very close proximity. The class didn't
add anything.
This improves readability and with the new state its easier to write
too.
tomFlowee
TomZ