Commit Graph

4 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
210c32d890
channeldb: add doc strings to finalize funcs/structs 2016-06-22 17:15:52 -07:00
Olaoluwa Osuntokun
c2818a549b
channeldb: modify schema to multiple-channels-per-peer
This commit overhauls the current schema for storing active channels in
order to support tracking+updating multiple open channels for a
particular peer.

Channels are now uniquely identified by an output (txid:index) rather
than an arbitrary hash value. As a result, the funding transaction is
no longer stored, as only the txin is required to lookup the original
transaction, and to sign for new commitment states.

A new bucket, nested within the bucket for a node’s Lightning ID has
been created. This new bucket acts as an index to the active channels
for a particular peer by storing all the active channel points as keys
within the bucket. This bucket can then be scanned in a linear fashion,
or queried randomly in order to retrieve channel information.

The split between top-level, and channel-level keys remains the same.
The primary modification comes in using the channel ID (the funding
outpoint) as the key suffix for all top-level and channel-level keys.
2016-06-21 13:12:43 -07:00
Olaoluwa Osuntokun
631e76519e channeldb: switch to Open/Create methods rather than New
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.
2016-03-23 22:11:57 -07:00
Olaoluwa Osuntokun
4fdb2763e6 channeldb: create new channeldb package, update lnwallet to use new API
* Initial draft of brain dump of chandler. Nothing yet set in stone.
* Will most likely move the storage of all structs to a more “column”
oriented approach. Such that, small updates like incrementing the total
satoshi sent don’t result in the entire struct being serialized and
written.
* Some skeleton structs for other possible data we might want to store
are also included.
* Seem valuable to record as much data as possible for record keeping,
visualization, debugging, etc. Will need to set up a time+space+dirty
cache to ensure performance isn’t impacted too much.
2015-12-26 12:35:15 -06:00