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.
Merkle-block and merkle-tree classes and methods are pretty much stand-
alone and can be moved with no efforts.
Also move the relevent unit test to qtestlib.
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.
The API call for GetBlock has a filter-on-address functionality which is
now ported to no longer use ripe160 addresses but instead uses output-
script hashes.
This avoids problems for transactions not using p2pkh and generally is a
cleaner solution.
This also adds a unit test to test this feature.
Remove addresses of type ripe160 to be used in the API of AddresMonitor
API service. Instead use a sha256 hash of the entire output script.
This is mostly internal changes not affecting the operations much.
The usage of a ripe160 for bitcoin addresses in the API and in the
Indexer loses some info, specifically what kind of script it is.
Additionally not all types of scripts fit this mold. At best that means
its not future-proof.
This adds a method to the API in order to select from a Tx the hashed
outscript (thats singlehashed sha256) and refactor the address indexer
to use that instead of the ripe160 address.
The API enums broke a little, so I used the opportunity to break it a
lot and clean up the enums in order to make them more future-proof.
But, yeah, software from before this commit is protocol incompatible
with software after this commit.
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.
This means that for apps like 'pos' no longer link against libSSL
The streams no longer zero-after-free, there are no secrets transported
in datastreams so this is useless and avoids linking in one OpenSSL
call.
The insecure_rand() method depended on the openssl code to seed it with
randomness. Now replaced with a proven current-time-milliseconds.
This is enough in those cases because it was always meant to be an
insecure random.
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.
The block-box tests have long ago lost their usefullness
and have all been replaced by c++ ones.
The big-box testing was always frowned upon, but it kinda worked
for the original Core codebase which was practically speaking 100%
single-threaded.
Flowee the Hub breaks lots of questionable assumptions.
For instance the assumption that sending a transaction to a node
via the p2p layer and then immediately sending a request over RPC for
the mempool will find that tx there.
Flowee uses an async p2p layer, and therefore that old assumption no
longer holds.
Also, its python. Which is painful to read.
TomZ