This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
To simplify the message signing API even further, we refactor the
lnwallet.MessageSigner interface to use a key locator instead of the
public key to identify which key should be signed with.
To simplify the API surface of a remote signer even more, we refactor
the SignMessage and SignMessageCompact calls to only accept a key
locator as we always know what key we're using for signing anyway.
To make it possible to use a remote lnrpc server as a signer for our
wallet, we need to change our main interface to sign the message instead
of the message's digest. Otherwise we'd need to alter the
lnrpc.SignMessage RPC to accept a digest instead of only the message
which has security implications.
To make it possible to use a remote signrpc server as a signer for our
wallet, we need to change our main interface to sign the message instead
of the message's digest. Otherwise we'd need to alter the
signrpc.SignMessage RPC to accept a digest instead of only the message
which has security implications.
In this commit, we extend the DerivePrivKey method to allow callers that
don't know the full KeyLocator information to attempt to derive a
private key via a brute force mechanism. If we don't now the full
KeyLoactor, then given the KeyFamily, we can walk down the derivation
path and compare keys one by one. In order to ensure we don' t enter an
infinite loop when given an unknown public key, we cap the number of
keys derived at 100k.
An upcoming feature to lnd that adds static channel backups will utilize
this feature, as we need to derive the shachain root given only the
public key and key family, as we don't currently store this KeyLocator
on disk.
In this commit, we fix a slight bug in the existing implementation of
DeriveNextKey for btcwallet. Before this commit, we would only set the
public key, and not also the derivation path. It's important that we
also set the path information, as in the near future we'll be using the
KeyDescriptors returned from this method to create static channel back
ups. With these static backups, the key alone may be insufficient to
re-derive the private key as we may need to fallback to brute forcing in
order to re-derive the key as it's possible we add new key families in
the future.
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.
