for internal purposes the network manager used std::list instances
for things that essentially were FIFO queues.
With high volume of packages being sent this causes a large overhead
and even a crash or two.
So I replaced them with ringbuffers which means that the normal
sending
of data will remove a large selection of mem allocations.
In applications we typically set a debug section
that is the default for that application so devs
can just call logInfo() without any arguments and
get the debug section for his app.
This now works with MessageParser::debugMessage() as well.
Add a filter option to allow clients to send addresses
and match outputs against those bitcoin addresses so
only transactions that spend those outputs match will
be incuded in the result.
Add a session state so clients can send a filter
and just reuse that filter in subsequent calls.
Demote the old RPC one to Legacy.
The old is still useful as it allows the 'verbose' version, but it uses
lots of deprecated tech and thus doesn't scale.
Mining currently runs a 'verifyOnly' step which is currently
entirely single-threaded because of CTOR.
Since we are collecting transactions from the mempool
it looks a bit odd to check what we already checked on
mempool-accept again.
The 'server' library has always been a catch-all and
ideally only the hub links it in (far future goal).
In line with this I move a list of files out of server
into the utils lib.
I choose 'utils' because all these are plain old data
objects that many crypto apps will find useful.
now in utils/primitives/
* CScript
* CPubKey
* CTransaction
* CBlock
* FastTransaction
* FastBlock
* CScript
streams.h is now in utils/streaming/
hash.h is now in utils/
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.
This is really only relevant for people using btrfs on Linux, we will
set the utxo dir to be no-copy-on-write which causes all new databases
to follow this flag and be faster due to lack of copying on write.
The reason there are no standard library versions of lock-free
containers is because you want to always take full advantage of
the details in question.
In this case (read millions of times for each modification) it makes
no sense to use anything other than a standard container, but put in
a copy-on-write block. Simple and easy.
TomZ