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.
Handle incoming payments, show if under/overpaid and
make sure everything is properly inserted into the database.
This makes the process actually work and useful for a small business
* logs.conf now also found directly in the homedir if there is no
$HOME/.config dir
* default filename is now 'hub.log' instead of 'debug.log'
* logs.conf now also detects ALL as a keyword for section
* logs.conf now also supports 'option path [path]'
So, now we install the example config file
Then we follow XDG for retrieving it.
We first check XDG_CONFIG (~/.config/flowee) and if we can't find a confg
file there fall back to the data dir (~/.local/share/flowee).
So the service only noticed new stuff happening, like a transaction
coming in or block being mined.
With this change we get a little smarter and look in the current mempool
as well to try and match a transaction.
This should be very useful for clients that lose network connection
briefly.
TomZ