The state of OpenChannel on disk has now been partitioned into several
buckets+keys within the db. At the top level, a set of prefixed keys
stored common data updated frequently (with every channel update).
These fields are stored at the top level in order to facilities prefix
scans, and to avoid read/write amplification due to
serialization/deserialization with each read/write.
Within the active channel bucket, a nested bucket keyed on the node’s
ID stores the remainder of the channel.
Additionally OpenChannel now uses elkrem rather than shachain, delivery
scripts instead of addresses, stores the total net fees, and splits the
csv delay into the remote vs local node’s.
Several TODO’s have been left lingering, to be visited in the near
future.
Commit includes basic tests for Open/Create. Additionally, rather than
relying on btcwallet’s addmgr for encryption/decryption, this package
now exposes a simple crypto system interface.
A file dedicated to handling+dispatching version information concerning
lnd. We’ll be using the semantic versioning standard.
I guess lnd is officially at 0.1.0-alpha now?
* 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...
