Commit Graph

20 Commits

Author SHA1 Message Date
Johan T. Halseth
7adb1bcbaa
chanbackup: disable channel backup for anchor types 2020-03-09 12:59:35 +01:00
Oliver Gugger
d4f836ecb3
chanbackup: encode broadcast height in chan ID for unconfirmed channels 2019-11-26 14:45:21 +01:00
Oliver Gugger
4728ac844a
chanbackup: continue recovery if channel already exists 2019-11-18 10:51:23 +01:00
Olaoluwa Osuntokun
a73ee28e46
multi: convert the existing channeldb.ChannelType uint8 into a bit field
In this commit, we convert the existing `channeldb.ChannelType` type
into a _bit field_. This doesn't require us to change the current
serialization or interpretation or the type as it is, since all the
current defined values us a distinct bit. This PR lays the ground work
for any future changes that may introduce new channel types (like anchor
outputs), and also any changes that may modify the existing invariants
around channels (if we're the initiator, we always have the funding
transaction).
2019-10-31 16:34:37 -07:00
Olaoluwa Osuntokun
c6ee42d3e2
chanbackup: create new Single version for tweakless commitment chans
In this commit, we create a new Single version for channels that use the
tweakless commitment scheme. When recovering from an SCB into an open
channel shell, we'll now check this field and use it to determine the
proper channel type. Otherwise, we may attempt to sweep the on chain
funds using the commitment point, when it goes directly to our key, or
the other way around.
2019-09-25 18:26:20 -07:00
Joost Jager
1e0ed1e52f
multi: fix dropped errors 2019-09-13 09:50:38 +02:00
Federico Bond
aea52f4bef multi: replace manual CAS with sync.Once in component start/stop
This guarantees callers that the method will not return until it
has executed completely at least once.
2019-05-30 17:14:04 -03:00
Olaoluwa Osuntokun
f40ddd36d5
chanbackup: close temp SCB file before rename
It has been reported that on Windows, the current file swap process
doesn't properly work since we still have the file open when we try to
rename it. In order to fix this, we'll now close the file _before_ we
rename it.
2019-05-27 15:36:55 -07:00
Conner Fromknecht
17ab813dcf
utxonursery+chanbackup: fix range loop binding bugs 2019-05-16 20:37:30 -07:00
Olaoluwa Osuntokun
7cbf0326c7
chanbackup: extend channel backups to include entire local+remote chan config
In this commit, we extend the prior Single format to include the entire
channel config, other than the constraints, but including the CSV delay
for both sides. We do this as we'll need more of the keying information
in order to properly execute the DLP protocol. Additionally, in the
future, if warranted, this would allow channels to be resumed if deemed
safe.
2019-03-28 17:53:38 -07:00
Olaoluwa Osuntokun
d7bc93b6d3
chanbackup: add new NilMultiSizePacked constant 2019-03-28 17:53:37 -07:00
Olaoluwa Osuntokun
af1dfe176e
chanbackup: add new updateBackupFile method, write fresh backup on startup
In this commit, we modify the sub-swapper to update the set of backups
files time it's tarted. We do this to ensure that each time we start,
we're up to sync with the current set of open channels. This also ensure
that we'll create a new back up file if this is the first time we're
starting up with this new feature.
2019-03-28 17:53:30 -07:00
Olaoluwa Osuntokun
3b370fa08d
chanbackup: add new sub-system for keeping the on disk channels.backup up to date
In this commit, we introduce the chanbackup.SubSwapper interface. It
takes a regular Swapper implementation (defined by the
chanbackup.SubSwapper) interface along with a chanbackup.ChannelNotifier
implementation. Given these two interfaces, we're able to be notified
when a new channel is opened or closed, and then use the Swapper to
atomically replace the on-disk channel back up. As a result, a Lightning
daemon can ensure that they alwayts have a up to date channels.backup on
disk that can safely be copied away by users and be used to restore
channel funds in the event of partial/total data loss.
2019-01-23 18:11:33 -08:00
Olaoluwa Osuntokun
60999df08f
chanbackup: add new MultiFile struct for storing+updating Multis on disk
In this commit, we add a new MultiFile struct. We'll use this struct in
store the latest multi-channel backup on disk, swap it out atomically,
and finally extract+unpack the contents of the multi-file. The format
that's written to disk is the same as a regular Packed multi. The
contents of this new file are meant to be used to safely implement an
always up to date multi file on disk as a way for users to easily rsync
or fsnotiy (when it changes) the backup state of their channels.

We implement an atomic update and swap in the UpdateAndSwap. The method
uses relies on the underlying file system supporting an atomic rename
syscall. We first make a temporary backup file, write the latest
contents to that, then swap the temp file with the main file using
rename(2). This way, we ensure that we always have a single up to date
file, if the protocol aborts before the rename, then we can detect this,
remove the temp file, and attempt another swap.
2019-01-23 18:11:31 -08:00
Olaoluwa Osuntokun
7fcab83bb4
chanbackup: add functions to allow recovery of existing channel backups
In this commit, we add a series of functions that will allow users to
recover existing channel backups. We do this using two primary
interfaces: the ChannelRestorer, and the PeerConnector. The first
interfaces allows us to abstract away the details w.r.t exactly how a
channel is restored. Instead, we simply expect that the channel backup
will be inserted as a sort of "channel shell" which contains only the
data required to initiate the data loss protection protocol. The second
interface is how we instruct the Lightning node to connect out to the
channel peer given its known addresses.
2019-01-23 18:11:29 -08:00
Olaoluwa Osuntokun
1348c6b35b
chanbackup: add functionality to allow external callers to backup channels
In this commit, we introduce a series of interfaces and methods that
will allow external callers to backup either all channels, or a specific
channel identified by its channel point. In order to abstract away the
details w.r.t _how_ we obtain the set of open channels, or their storage
mechanisms, we introduce a new LiveChannelSource interfaces. This
interfaces allows us to fetch all channels, a channel by its channel
point, and also all the known addresses for a node as we'll need this in
order to connect out to the node in the case of a recovery attempt.
2019-01-23 18:11:28 -08:00
Olaoluwa Osuntokun
71df4b0545
chanbackup: introduce Multi, a multi-channel backup
In this commit, we introduce the Multi sturct. Multi is a series of
static channel backups. This type of backup can contains ALL the channel
backup state in a single packed blob. This is suitable for storing on
your file system, cloud storage, etc. Systems will be in place within
lnd to ensure that one can easily obtain the latest version of the Multi
for the node, and also that it will be kept up to date if channel state
changes.
2019-01-23 18:11:27 -08:00
Olaoluwa Osuntokun
ee71e16593
chanbackup: add implementation of Single Channel Backups (SCBs)
In this commit, we add the initial implementation of the SCB structure.
Given an SCB, and a user's seed, it will be possible to recover the
settled balanced of a channel in the event of total or partial data
loss. The SCB contains all information required to initiate the data
loss protection protocol once we restore the channel and connect to the
remote channel peer.

The primary way outside callers will interact with this package are via
the Pack and Unpack methods. Packing means writing a
serialized+encrypted version of the SCB to an io.Writer. Unpacking does
the opposite.

The encoding format itself uses the same encoding as we do on the wire
within Lightning. Each encoded backup begins with a version so we can
easily add or modify the serialization format in the future, if new
channel types appear, or we need to add/remove fields.
2019-01-23 18:11:26 -08:00
Olaoluwa Osuntokun
d98a7e8138
chanbackup: add logger 2019-01-23 18:11:25 -08:00
Olaoluwa Osuntokun
67c6d0d331
chanbackup: implement crypto operations for serialized static channel baackups
In this commit, we implement a series of new crypto operations that will
allow us to encrypt and decrypt a set of serialized channel backups.
Their various backups may have distinct encodings when serialized, but
to the functions defined in this file, we treat them as simple opaque
blobs.

For encryption, we utilize chacha20poly1305 with a random 24 byte nonce.
We use a larger nonce size as this can be safely generated via a CSPRNG
without fear of frequency collisions between nonces generated. To
encrypt a blob, we then use this nonce as the AD (associated data) and
prepend the nonce to the front of the ciphertext package.

For key generation, in order to ensure the user only needs their
passphrase and the backup file, we utilize the existing keychain to
derive a private key. In order to ensure that at we don't force any
hardware signer to be aware of our crypto operations, we instead opt to
utilize a public key that will be hashed to derive our private key. The
assumption here is that this key will only be exposed to this software,
and never derived as a public facing address.
2019-01-23 18:11:21 -08:00