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.
This service allows one to connect it and register any number of
bitcoin-addresses which will then cause any transaction or block
coming in the future lead the subscriber to get notified about
such events.
To allow configurability, don't give the whole 1000 sections a
real component, let them be a meta-group.
Also add the upcoming POS (point of sale) component.
TomZ