Since the default copy constructor of the HDMasterKey uses the copy
constructor of CKey, make the latter have a copy constructor explicitly
defined as well.
setting an incorrect value should not keep the old data after we already
update the fValid boolean.
That would give the user the impression that the data was removed while
it really isn't.
This avoids a naming conflict with a p2p class BlockHeader.
Notice that the block data structures are mostly still private API, they
are in the utils dir but headers are not installed, nobody has needed
them so far.
This avoids checkers being worries about the inconsistency of a
specific copy-constructor but a generic assignment operator.
The assignment operator can be generic because locking doesn't
care what the content is.
The code that connects blocks together uses the block-hash (blockId) for
that, which we always just created on the fly.
Instead store the blockId on the state and in that way make adding
headers not entirely in-sequence be 10 times as fast.
Additionally, we wait with actual validation after a reindex until the
files are all found because otherwise we can't save the meta blocks.
People all over the Internet, including on the BCH spec, seem confused
about these enum values. They think they are opcodes.
So lets be clear and rename them to the thing they are. Placeholders or
a return-code.
This does remove the feature that mining can use the internal wallet as
a source of coinbase addresses, but since Flowee doesn't actually ship a
wallet, that was just not a good reason to keep an unused class in the
libs.
The CAmount name is not helpful as its just an int64_t and not a
class, like the name implies. There were a handful of places where
it was passed in as const-ref, as a good example of this actually
creating sub-par code.
The method offsetInBlock assumes the block actually is the one this
transaction is in, the assert helps making sure that this assumption
isn't broken, prodicing unusable results.
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
tomFlowee
TomZ