This commit fixes a bug that would cause the
notifier not to commit spend hints for items
that are not found. This is done by calling
UpdateSpendDetails with a nil detail, permitting
the notifier to begin updating the spend hints
with new blocks that arrive at tip. The change
is designed to mimic the behavior for historical
confirmation dispatch.
The symptom of this bug is needing to do many
long rescans on startup, even if new blocks
arrive after the rescan had completed. With
this change, nodes will have to do the scans
once more before their hints will be properly
updated. Restarts from then on should not
have this behavior.
In this commit, we add 4 new itests for exercising the SCB restore
process via 4 primary scenarios: recover from backup using RPC, recover
from file using RPC, recover channels during init/creation, recover
channels during unlock. With all fields populated there're a total of 24
new scenarios to cover. At the time of authoring of this commit, the
other scenarios (bits are: initiator, updates, private) have been left
out for now, as they increased the run time of the integration tests
significantly.
In this commit, we modify the core testDataLossProtection test to
extract the primary DLP assertion logic into a new function. We do this,
as the upcoming SCB tests will fallback to this test after some initial
set up.
In this commit, we update all uses of the `getChanPointFundingTxid` to
match the new function signature. We no longer need to convert to a
chainhash.Hash, as the method does so underneath now.
In this commit, we modify the `RestoreNodeWithSeed` and `RestartNode`
methods to also accept an SCB. This will be useful in new integration
tests to properly exercise the various restore/restart scenarios using
static channel backups.
During the restore process, it may be possible that we have already
heard about our prior edge from a node on the network (or our channel
peers). As a result, we shouldn't exit if this happens, and instead
should continue with the rest of the restoration process.
In this commit, we convert the server's Start/Stop methods to use the
sync.Once. We do this in order to fix concurrency issues that would
allow certain queries to be sent to the server before it has actually
fully start up. Before this commit, we would set started to 1 at the
very top of the method, allowing certain queries to pass before the rest
of the daemon was had started up.
In order to fix this issue, we've converted the server to using a
sync.Once, and two new atomic variables for clients to query to see if
the server has fully started up, or is in the process of stopping.
In this commit, we modify the `closeObserver` to fast path the DLP
dispatch case if we detect that the channel has been restored. We do
this as otherwise, we may inadvertently enter one of the other cases
erroneously, causing us to now properly look up their dlp commitment
point.
In this commit, we modify the main `closeObserver` dispatch loop to only
look for the local force close if we didn't recover the channel. We do
this, as for a recovered channel, it isn't possible for us to force
close from a recovered channel.
In this commit, we modify the `ChanSyncMsg` to send an invalid
commitment secret in `ChanSyncMsg`. We do this in order to force the
remote party to force close off-chain, if we're restoring a channel from
scratch and we never had any state updates within the channel. We need
to do this, as otherwise the remote party will think we can resume as
they're able to verify their own commit secret for state zero.
In this commit, we convert the Unlock method to accept the
`lnrpc.UnlockWalletRequest`. This makes things a bit more generic as we
no longer need to continue to add params to the method each time a new
field is added to the Unlock method.
In this commit, we modify the `AddrsForNode` method to not fail if no
graph node is found. We do this as when the backup is being
restored/created, it's possible that we don't yet have a
NodeAnnouncement for that node.
In this commit, we move the location where we restore the channel status
to within the `RestoreChannelShells` method itself. Before this commit,
we attempted to use `ApplyChanStatus` which creates a DB transaction and
relies on a fully populated channel state, which in the restoration
case, we don't yet have.
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.
In this commit, we add a new config option: `backupfilepath` for the new
SCB implementation. This argument allows users to specify a custom
location for the SCB file such as NFS or distinct partition.
In this commit, we add the channelNotifier, and implementation fo the
chanbackup.ChannelNotifier interface. This will be our bridge from the
channelnotifier.ChannelNotifier sturct within lnd, and the interface
abstraction that the chanbackup.SubSwapper accpets. The role of this new
struct is simple: proxy the messages from the
channelnotifier.ChannelNotifier to the chanbackup.SubSwapper in a format
that it understands.
Along the way we introduce a tiny interface such that we don't need to
depend on the the channledb package.
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.
In this commit, we add two new cli commands: exportchanbackup and
restorechanbackup. These two commands allow users to export backups
(single or multi) for one or all channels, and also restore these
backups (single or multi) from a file to attempt to recover the
channels.
Additionally, we extend the `lncli create` call to also accept these
backups so users can have a single command to restore both their
on-chain and off-chain funds.
In this commit, we modify the server to serve the role as the agent
which will carry out the SCB restoration protocol if the Init/Unlock
methods include a set of channels to be recovered.
The `openChannelShell` method now includes the new config information
within the open channel shells. Additionally, we now properly re-derive
all keys from our local chan config so they're useable immediately in
the channel state machine.
We extend the `chanDBRestorer.RestoreChansFromSingles` method to also
add the new channels to the chain arbitrator once they've been restored
on disk. We do this in order to ensure that we catch the channel closure
on chain once the DLP protocol beings.
In this commit, we modify the filter we use to determine if we should
add a new channel to the switch to reflect the new channel restoration
state. For all other non-default states, we want to avoid loading in a
channel, but for the restoration state, we need to load the link in
order to ensure we initiate the data loss protection protocol once we
connect to the remote peer.
In this commit, we we extend the Init and Unlock methods to also parse
out and return optional SCB instances. With this change, when the user
creates their node, if they have an existing seed and also a set of SCBs
(either single or multi), they'll be able to recover both their on-chain
balance, and also any funds that were settled within their existing
channels.
In this commit, we upgrade regular KeyRing instance to a SecretKeyRing
instance as we need the upgraded instance in order to recover SCB's. Due
to the fact that we don't currently store the full KeyLocator for the
key used to derive a shachain root for each channel, we instead need to
obtain the private key vanilla to re-derive this value.
In this commit, we address an assumption of the gossiper's recently
introduce reliable sender. The reliable sender is currently only used
for messages of unannounced channels. This makes sense as peers should
be able to retrieve messages from the network if they've previously
announced. However, within isMsgStale, we assumed that the reliable
sender would be used for every ChannelUpdate being sent, even if the
channel is already announced. Due to this, checking if the policy is
stale was unnecessary. But since this isn't the case, we should actually
be checking whether it is stale to prevent sending it later on.
