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
seems to work OK. Could be sped up by local filters instead of
ingesting every tx from the block but I can do that later if
performance (mostly disk i/o) is an issue
once multiple connections are implemented, hard mode should forward
txs to blend in.
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
add a bool to the HashAndHeight struct;
can indicate "final". When the block market final comes in,
we don't enter wait state, but instead ask for headers.
when you don't get any headers, you wont need any blocks, and that
will assert the wait state.
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.
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
