* API docs
* Fix possible race condition in addOrphan()
* Reject proofs that violate simple constraints
* clear up possible confusing API (first/double spender getters).
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.
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.
This was always the intention, but the satoshi code was stupid and buggy.
First, the 'version has been seen' flag was set even if there was a parsing
error in it.
Second, ignoring messages (up to 100) until a version message was seen
makes no sense. Just disconnect instantly.
When, on loading, the blockindex and the UTXO don't agree then try to find an older UTXO
state where they do agree.
The most typical state issue is where a block stored in the blocksdb is not available in
the index due to corruption or similar.
To allow the UTXO to actually use the power of checkpoints we need to
make sure that the block-validation state is not stored separately from
it.
The goal is that when we have some curruption we can just go back to an
earlier state of the UTXO and re-validate the blocks to get to the
current tip. The often seen problem is that corruption will instead
leave the block-index (leveldb) with an incorrect state so the replay
fails.
This change solves that by no longer reading the block-validation-state
and no longer writing it on a state change.
This improves the double spend proof orphans code.
Also add a DSProof log-category and lots of log lines to make
looking at a debug build much more fun.
Move some files back to the server "library".
Merge the 'console' lib with server, as it doesn't really make sense with
just one file and nobody exclusively linking to it.
The server "libary" is not really a library, its the place we put all
the files shared by hub-qt hub-cli and hub.
We no longer depend on these files from other places (mostly due to
moving to the new logging framework) and as such we can move the files
back.
We used various ways to enable new features over the last 10 years.
We can remove that legacy code and just set the blockheight.
This cleans up the code quite a bit.
Move some globals and all stuff pulling in crypto to the
server/serverutil.cpp file
Remove dead code.
Move several items that were used in only one place to the respective
files using them.
Move the class WaitUntilFinishedHelper into its own file.
Made sure no header includes utils.h
remove a handfull of files including utils.h for nothing.
This removes the attempt at magic (predicting future) component
called the fee-estimator.
The direct effect is that all transactions have as a mempool acceptance
the same minimum fee. Regardless of how full the mempool or blocks were.
This mempool-acceptance minimum fee is 0 sat/byte. (aka free)
Notice the node-wide free-tx accept-limiter is going to avoid us getting
overloaded.
* user selected nodes (using -connect=) are whitelisted, which allows
them to get your headers even if you are still in initial download.
* Avoid crash in a starting node in isInInitialDownload when
pIndexBestHeader was still null.
The "UAHF" one used to be "more equal", mostly just because it happened
to be the first.
This makes them all equally equal.
Specifically this removes the special casing and the enum for the 201708
HF (aka BCH fork-point).
We select the right branch now purely based on the historical check-
points.
Nodes that follow a different chain (and thus send us headers that we
already invalidated) now get an immediate disconnect whereas before
we could keep them around for an hour.
Remove txIndex option, its move to Flowee Indexer
Also remove the GUI option for setting the amount
of "script validator threads". :D
Remove DBCash command line option too, equally obsolete.
Should you have a hub already running then starting a second aborts
at startup.
Since the shutdown sequence is run it tries to save everything.
This fix avoids a nullptr dereference in this specific event.
As the miners have started using the block-version bits for their
own purposes this means that BIP9 checks are rather irrelevant.
Signalling using version bits is rather silly anyway.
In Flowee there will no longer be warnings generated based on
these now outdated assumptions.
And this means less code :)
During the BCH fork-off time we allowed the client to be started
as either BCH or BTC and as such there are several code-paths
that behave different based on this user setting.
We remove those as we no longer allow starting as BTC client.
This also removes the check for the min-block-size (rollback protection)
as this is accomplished by the checkpoints on the BCH chain.
TomZ