In this commit, we update lnd to now access the deterministic
keychain.KeyRing struct in order to obtain our identity public key.
With this change, if the user recovers their wallet with the same seed,
then they’ll have access to the same prior node identity. This change
also makes it easy for us to support node key rotation in the future by
bumping up our requested index.
In this commit, we modify the mechanics of the wallet to only allow
derivation of segwit-like addresses. Additionally, the ConfirmedBalance
method on the WalletController now only has a single argument, as it’s
assumed that the wallet is itself only concerned with segwit outputs.
In this commit, we modify the way we generate the secrets for
revocation roots to be fully deterministic. Rather than use a special
key and derive all sub-roots from that (mixing in some “salts”), we’ll
use the proper keychain.KeyFamily instead. This ensures that given a
static description of the channel, we’re able to re-derive our
revocation root properly.
In this commit, we modify the funding flow process to obtain all keys
necessary from the keychain.KeyRing interface. This ensure that all
keys we generate are fully deterministic.
In this commit, we remove references to raw keys from the main
ChannelConfig struct and instead replace it with usage of
keychain.KeyDescriptor. We do this, as the ChannelConfig as it stands
is a near complete static description of a channel. In the future, it
will be possible to export these static descriptions as backups. We
prefer the KeyDescriptor of a plain PublicKey, as the KeyLocator
portion of the struct allows a stateless signer to re-derive the keys
as needed when signing.
In this commit, we update the SignDescriptor struct to instead use the
keychain.KeyDescriptor struct inplace of a raw public key. We do this
as this allows for a recovery mode, where the caller doesn’t know what
key was used exactly, but remembers the precise KeyDescriptor. A
stateless signer is still able to re-derive the proper key, as it’s
given the full path.
The new version of the internal core of btcwallet now uses KeyScopes
rather than address types to derive particular addresses. As a result,
in this commit, we update our API usage to ensure that proper addresses
are still derived.
In this commit, we remove two methods from the WalletController
interface which were previously used by the funding reservation process
(NewRawKey) and the p2p network (FetchRootKey) in order to derive
various keys for operation. This methods are no longer necessary as the
KeyRing interface implements the functionality in a deterministic
manner.
In this commit, we add a new package to lnd: the keychain package. The
role of this package is to house all the interfaces that lnd will use
to generate the various keys it needs to create contracts and operate
within the network. Additionally, we also use this package to define a
deterministic key derivation scheme, that can be implemented by any
software/hardware that partially understands BIP43-like derivation.
The first version (v0) of the keychain schema is very simple. We re-use
BIP43, with a slight twist. Re-using BIP43 lets us leverage all the
existing libraries out there as far as compatibility. The purpose used
is 1017, and the coin type, the particular coin type of the chain where
the keys are meant to be used. Within our schema, we define multiple
“key families”. Each key family is actually just manifested as a new
“account” within the BIP44/43 family. With this schema, if we have
static description of the keys used within a channel, given the seed,
and the “KeyLocator”, we can re-derive all keys necessary be able to
re-sign for the channel.
In this commit, we add a new method to the RPC service:
ForwardingHistory. This method will allow callers to query for the
completed payment circuits in a particular time slice, skip a series of
events, and also paginate within a time slice.
In this commit, we extend the switch as is, to record details
concerning settled payment circuits. To do this, we introduce a new
interface to the package: the ForwardingLog. This is a tiny interface
that simply lets us abstract away the details of the storage backing of
the forwarding log.
Each time we receive a successful HTLC settle, we’ll log the full
details (chans, fees, time) as a pending forwarding log entry. Every 15
seconds, we’ll then batch flush out these entries to disk. When we’re
exiting, we’ll try to flush out all entries to ensure everything gets
recorded to disk.
We’ll need this value within the link+switch in order to fully populate
the forwarding event that will be generated if this HTLC circuit is
successfully completed.
In this commit, we add the incoming+outgoing amounts if the HTLC’s that
the payment circuit consists of. With these new fields, we’ll be able
to populate the forwarding event log once the payment circuit has been
successfully completed.
In this commit, we add a new storage namespace to channeldb: the
ForwardingLog. This log will be used by higher level sub-systems to log
each successfully completed HTLC. Each payment circuit will be
summarized as a “ForwardingEvent”. A series of events can then be
queried via a time slice query. In a time slice query, the caller
specifies a time range, a number of events to skip, and the max number
of events to return. Each query will return the index of the final
item. As we have a max number of events we’ll return in a response,
callers may need to use this last offset index to seek further by
skipping that number of entries. Combining these fields, callers are
able to query the time series, skipping an arbitrary amount of events,
and capping the max number of returned events.
In this commit, we reduce the amount of unnecessary work that the
gossiper can carry out. When CPU profiling some nodes, I noticed that
we’d spend a lot of time validating the signatures for an announcement,
only to realize that the router already had it.
To remedy this, we’ll use the new methods added to the channel router
in order to avoid unnecessarily validating an announcement that is
actually stale. This should reduce memory usage (since it uses big
int’s under the scenes), and also idle CPU usage.
In this commit, we add a set of new methods to check the freshness of
an edge/node. This will allow callers to skip expensive validation in
the case that the router already knows of an item, or knows of a
fresher version of that time.
A set of tests have been added to ensure basic correctness of these new
methods.
In this commit, we extend the `lncli create` command to allow users to
specify their own side (if they want). In the case that the user
*doesn’t* specify their own seed, we’ll return the entropy generated by
the wallet in a 24-word mnemonic format for easy backup.
With this change, it’s now possible for users to restore an existing lnd
wallet seed.
In this commit, due to the recent changes within lnd itself, it may be
possible that a wallet already exists when the wallet has been signaled
to be created. As a result, *always* open the wallet ourselves, but
allow an existing wallet to already be in place.
In this commit, we extend the initial wallet creation set up case with
the goal of giving the user the ability to restore a prior wallet from
seed, or obtain the mnemonic for a newly generated wallet.
As the WalletUnlocker has been extended to allow passing a user source
of entropy, if this is detected, then we’ll use BIP39 to covert it into
an HD wallet seed. Otherwise, we’ll generate our own entropy, then
convert that into the wallet seed.
In order to make this change, we’ll now manually create the default
wallet ourselves. In the case that the user didn’t provide their own
seed, we’ll send the seed we generated back to the user. This will allow
frontends to display the newly generated seed to the end user.
In this commit, we extend the UnlockerService to account for the new
changes in the lnrpc definition. Setting up the daemon for the first
time is now two step process: first the user will generate a new seed
via the GenSeed method, then the user will present this new seed (and
optional pass) to the InitWallet method which then will finalize the
wallet creation.
This two step process ensures that we don't commit the wallet changes
in the case that the user doesn't actually "ACK" the new seed.
In the case that the user already has an existing seed, they can
re-enter it and skip straight to the InitWallet step.
We also update the tests to account for the new API changes.
