Commit Graph

108 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
87603e780f channeldb: re-design OpenChannel schema, update tests
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.
2016-03-23 22:39:52 -07:00
Olaoluwa Osuntokun
3e3948a04f channeldb: switch to bolt.DB instead of walletdb.DB
This decouples channeldb from btcwallet, and also allows us access to
bolt’s Batch() call.
2016-03-22 18:46:30 -07:00
Tadge Dryja
2815afebb7 update imports to github 2016-01-16 10:45:54 -08:00
Olaoluwa Osuntokun
c4af4017da channeldb: revocation hashes are 20 bytes
* Although, why not 32?
2016-01-14 23:56:08 -08:00
Tadge Dryja
8504362c5e trying to store id pkh. Doesn't work; wallet creation never completes 2016-01-14 23:56:08 -08:00
Tadge Dryja
e70c6aa367 trying to store private identity key. Doesn't work. 2016-01-14 23:56:08 -08:00
Olaoluwa Osuntokun
1b9d34f614 channeldb: don't store commit sig separately, expected to be within the txin of the commit tx 2015-12-29 00:00:29 -06: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