This commit modifies the composition of the boltdb pointer within the
DB struct to use embedding.
The rationale for this change is that the daemon may soon store some
semi-transient items within the database which requires us to expose
the boltdb’s transaction API. The logic for serialization of this data
will likely lie outside of the channeldb package as the items that may
be stored in the future will be specific to the current sub-systems
within the daemon and not generic channel related data.
In this commit the upgrade mechanism for database was added which makes he current schema rigid and upgradeable. Additional bucket 'metaBucket' was added which stores
key that house meta-data related to the current/version state of the database. 'createChannelDB' was modified to create this new bucket+key during initializing. Also
backup logic was added which makes a complete copy of the current database during migration process and restore the previous version of database if migration failed.
This commit adds persistence for a channel’s
TotalSatoshis[Sent|Received] fields. Also, the functions that perform
this persistence were renamed from [put|delete|fetch]ChanTotalFlow to
[put|delete|fetch]ChanAmountsTransferred.
This commit modifies the ChannelType enum to no longer use iota as
changes in the definition would cause the values to shift, breaking the
long-term stability required for persistence. Instead, we now select
values manually to indicate the particular channel type.
This commit modifies the existing OpenChannel struct slightly to store
a bool which indicates if we were the one who initially initiated the
channel or not. This information is relevant as in the current draft of
the specification, much of the fee related negotiation is contingent on
who initiated the channel.
This commit removes all prior fee tracking attributes along with the
persistence code from OpenChannel. The rationale is that fees actually
don’t exist at the channel level, and instead should be tracked at
higher level of abstraction as fees come from the inbound/outbound
satoshi spread.
This commit modifies the OpenChannel struct along with all related
persistent to additional store a single byte which indicates the exact
type of the channel. This may be useful in the future as higher level
behavior may change depending on the precise type of the channel.
This commit adds a new method ‘FullSyncWithAddr’ which is identical to
the existing ‘FullSync’ method other than it also creates an
association from the channel to a LinkNode object within the database.
This new method is required in order to create persistent links between
channels and link nodes which will later allow the development of
heuristics which decided when it “makes sense” to close a channel due
to inactivity. Additionally, this new association will allow for a
sub-system within the daemon to attempt to establish persistent
connections out to all LinkNodes in order to strive for channel
availability.
This commit slightly modifies the existing structure of the channeldb
scheme to replace the former concept of a “nodeID” with simply the
compressed public key of the remote node. This change paves the way for
adding useful indexes mapping a node to all it’s active channels and
the other way around.
Additionally, the current channeldb code was written before it was
agreed by many of those implementing Lightning that a node’s ID will
simply be its compressed public key.
This commit consists of a mass variable renaming to call the pkScript being executed for segwit outputs the `witnessScript` instead of `redeemScript`. The latter naming convention is generally considered to be reserved for the context of BIP 16 execution. With segwit to be deployed soon, we should be using the correct terminology uniformly through the codebase.
In addition some minor typos throughout the codebase has been fixed.
This commit introduces the concept of a manually initiated “force”
closer within the channel state machine. A force closure is a closure
initiated by a local subsystem which broadcasts the current commitment
state directly on-chain rather than attempting to cooperatively
negotiate a closure with the remote party.
A force closure returns a ForceCloseSummary which includes all the
details required for claiming all rightfully owned outputs within the
broadcast commitment transaction.
Additionally two new publicly exported channels are introduced, one
which is closed due a locally initiated force closure, and the other
which is closed once we detect that the remote party has executed a
unilateral closure by broadcasting their version of the commitment
transaction.
This commit splits the previously added RecordChannelDelta method into
two distinct methods: UpdateCommitment and AppendToRevocationLog. The
former method is to be used once the local party revokes their current
commitment, and the latter method to be used once the remote party
revokes their current commitment.
With the addition of the UpdateCommitment method, the active HTLC’s
from the local node’s point of view are now persisted to disk.
Snapshots returned by the channel now also includes the current set of
active HTLC’s. In order to maintain thread safety the channels mutex is
now grabbed within methods which modify/read state but don’t do so
solely via a boltDB transaction.
The tests have been updated to account for the storage of HTLC’s needed
in order to assert proper behavior.
This commit removes the revocation hash/keys from the channel deltas.
In the case of an uncooperative closure, we can efficiently re-generate
the proper elkrem pre-image so this storage was completely unnecessary
This commit implements a state update log which is intended the record
the relevant information for each state transition on disk. For each
state transition a delta should be written recording the new state. A
new method is also provided which is able to retrieve a previous
channel state based on a state update #.
At the moment no measures has been taken to optimize the space
utilization of each update on disk. There are several low-hanging
fruits which can be addressed at a later point. Ultimately the update
log itself should be implemented with an append-only flat file at the
storage level. In any case, the high level abstraction should be able
to maintained independent of differences in the on-disk format itself.
This commit removes the storage+encryption of private keys within
channeldb. We no longer need to encrypt these secrets before storing as
the base wallet is now expected to retain full control of these secrets
rather than the database.
As a result, we now only store public keys within the database.
This commit removes the EncryptorDecryptor interface, and all related
usage within channeldb. This interface is no longer needed as wallet
specific secrets such as private keys are no longer stored within the
database.
This commit fixes a bug caused by overriding the prefix key for storing
commitment keys with the first few bytes of a channel’s channel point.
Once a channel was deleted, then all future channels would result in a
panic due to a nil pointer deference since the prefix key was mutated,
causing all future stores/gets to fail.
We now also store their current revocation hash which is given to us
along with the revocation key once an initial HTLC is added to a
commitment transaction.
This commit updates the stored on-disk channel state to store a current
revocation key rather than a revocation hash. This change coincides
with the new commitment transaction format which uses revocation keys
rather than hashes.
Additionally, this commit updates the decoding/encoding of local+remote
elkrem trees to the latest changes in the elkrem API.
This commit introduces the concept of “closing” an already active
channel. Closing a channel causes all the channel state to be purged
from the database, and also triggers the creation of a small “summary”
kept concerning details of the previously open channel.
This commit also updates the previous test case(s), and includes the
close channel bucket in the database deletion in the .Wipe() method.
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.
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.
* 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.
