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.
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...
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
To try uspv, do ./lnd -spv
The remote node is hardcoded in shell.go. If you aren't
running a full node on localhost, specify where to connect to.
Nearby nodes will be much faster but random testnet nodes on the
internet should also work.
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.
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
