there were a lot of dumb things in Ingest() that made it really slow.
Like re-hashing the tx a bunch of times. And re-saving it to the
db redundantly.
also added local bloom filters. Maybe some concurrency issues if you
generate an address just as you're getting a tx with that address but
that doesn't seem like a real problem. Cheap to rescan anyway.
So it's faster and works better.
again with keys / values within the bolttx acting weird.
it wasn't deleting utxos that had been spent by the ingested tx.
it'd do the first 30 then stop. Deferred deletion and copied the
serialized utxo. Not sure which of those fixed it. Maybe both.
all adrs can be converted on the fly and displayed both ways.
in the actual UI this shouldn't happen though.
Also utxos are sorted and signed properly. utxo selection
is still pretty low tech.
here is code to keep track of two sets of addresses -- the
regular ones and the witness ones. But maybe those should be
merged becuase it's easy for other wallets to switch between them
and send to the same 20 byte pubkey hash but wintessified.
So maybe I'll change this stuff...
seems to go a little faster but not much.
making ingest tx take a slice of txs would be faster probably.
but it seems network i/o is the limiting factor so maybe it's OK
move methods to new files to keep things a bit organized.
add rebroadcast of unconfirmed txs after sync
mutex on OKtxid map
deal with doublespends next
Synchronization now seems to work well even with the rapid fire
many inv-block messages that I'm seeing often on testnet3. I'm
not 100% sure measuring the len() of a buffered channel is safe
but it seems to work fine.
Got rid of 'sum' in the TxStore; can be computed from GetAllUtxos()
Might want to merge SCon and TxStore since there's not much going
on in TxStore any more...
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.
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.
