pretty much everything is db based now. Still some concurrency issues
when multiple block inv messages come in (which they do) where
we used len(mBlockQueue) as a check for being synched up, which doesn't
quite work. Find a better way to do that...
Sync was non-deterministic because ingest was concurrent.
Now receiving tx messages is blocking, but that's OK, they really need
to be in the right order because the whole point of bitcoin is to put
txs in the right order. SendTx still has a problem that the change address
may not be recognized by ingest.
Seems that merkle blocks can return txs out of sequence, unlike
regular blocks which have to be in temporal/sequential order.
so maybe want to absorb ALL txs from mblock, then expel all?
I'm getting away from having both in-ram and on-disk stores for the transaction store data.
it should all be on disk, it's safer that way. It might be slower but this will not
process many txs / second anyway.
when we get inv messages, txs are easy but blocks are a little tricky
block heigh synchronization is done via os' file system
signing is a bit inelegant (searches through inputs for pkscript matches)
but fast enough in practice
