* Rather than rely on the legacy notification interface which may be
deprecated in the near future, we’ll now switch to using the
NotificationSever.
* Negative confirmation notifications due to re-orgs are still
unimplemented however.
* Re-orgs are still unhanded.
* RegisterSpendNtfn should perhaps also register directly with the rpc
client instead of pushing the responsibility to the caller.
* The `NotificationTrigger` struct has been dropped. Instead we know
simply employ a non-blocking send over a chan struct. This moves the
responsibility of triggering callbacks a level above to the registering
client.
* Confirmation notifications also now have a counter part in order to
notify a caller of the scenario wherein a funding transaction drops out
of the chain due to a re-org. A “neagtiveConf” value will be sent to
the client over a channel in this case. This will allow a caller to
re-register for another confirmation notification. Note that due to
this scenario, callers should also register for notifications
concerning spends of the counterparty’s inputs to the funding
transaction. If a second spend (other than the funding) is detected,
the channel should be closed immediately.
* Notifications concerning spends now also include the spending
transaction, hash, and the input on the spending transaction at which
the outpoint is spent.
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...
It doesn't work; can ingest out of order within a block,
so if a block has gain then loss, you might read it as loss
then gains, missing the loss.
Also, tryna implement p2wpkh
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.
* Previously, if the call to SetUp(..) returned an error, then the test
harness would fail to stop the running bcd process, and clean up the
test directories. This would cause any subsequent tests to fail. This
commit remedies this scenario.
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.
Allows us to remove a lot of duplicated code pertaining to wallet
setup. We also gain hooks into the wallet to trigger callbacks once the
wallet is created/opened.
Instead of creating “fake” utxos for bob, and alice. We now employ a
dedicated mining node to hand out utxos, and generate blocks with hand
picked transactions.
