This change makes the limits be static variables, which means they are
only settable once for a process. The only usecase so far is to use much
smaller limits in testing situations.
Flowee changed in that regtest has to be given on the commandline
allowing different config files for different chains.
So pass the regtest on the commandline.
On all mature operating systems and filesystems creation of a 1GB file
will not actually use that data, only when we start using blocks does
the disk space get used.
As such this is a premature optimization that Core added and I ported to
Flowee which this commit removes.
Additionally, increase the block file size to 1GiB
Duplicate the test_bitcoin file into the common dir,
I hope to remove the original in future.
Make the common dir a new static lib and create a new
qtestlib based unit test out of the old doublespend unit test.
together with blockFinished() as 'commit' this introduces the ability
to modify the in-memory utxo which can be rolled-back with ease.
This allows us to "modify" the utxo while validating a block in an
optimistic manner and only spend extra resources doing a rollback
should the block end up not being Ok.
The new UnspentOutputDatabase classes are only very loosly a database, we
purely register and store unspent outputs there. But unline a DB we don't
allow modification (just insert and delete).
This replaces the coin-db (which was based on leveldb) and as first goal
this gives us a higher level of stability. The level-database was known
to give corruption issues.
Notice that users will need to do a manual reindex on first update.
The old was based on levelDB which has scalability issues and stability
issues. (most often cited problem is corrupted database..)
This unspent output database I wrote is based on the idea that we need
never actually update any rows, which makes most old fashioned databases
a bad fit.
All we do is create rows and we forget rows. So lets design a DB to fit
that pattern.
Remove no longer useful options;
* chain (sorry, supporting the btc chain just doesn't seem worth it)
* initiatecashconnections, we only allow Cash connections now.
* flexiblehandshake, same for incoming. Reject non-cash ones.
The compact-message-format has numberic limits that were not
being managed well.
This unit test makes sure we keep the limits at;
Negative number is 0x7FFFFFFF (aka INT_MIN)
Positive number max is 0xFFFFFFFFFFFFFFFF (aka ULONG_LONG_MAX)
The inconsistent limits is because the API. We use ints for negative
numbers and unsigned-longs for larger numbers.
This keeps the API simpler for the common cases.
Get rid of the weird boost signals setup
Move it to a new library 'interfaces' which is
for stuff that has no dependencies and can avoid
creating inter-library or cicular dependencies.
TomZ