* The tests as written will be general to all future implementations of
ChainNotifier allowing future implementers to easily ensure their
implementation meets the expected behavior.
* The tests will be moved to the outer directory once a registration
mechanism for notifier implementations is in place.
* Turns out the NotificationServer on btcwallet doesn’t sever full
blocks, nor notify for arbitrary transactions. Instead, we now create a
new client specifically for BtcdNotifier.
* Final implementation is simpler, less dependent on newer btcwallet
features in flux. Additionally, this decouples the chain notifications
from the wallet. Enabling reliance on btcd for notifications, in
conjunction with an independent wallet that satisfies the to-be-drafted
Wallet interface.
* 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.
