Commit Graph

3374 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
f2192f1b90
cmd/lncli: remove p2pkh as an option for the new address command 2018-03-06 16:04:05 -05:00
Olaoluwa Osuntokun
1669e3d5ec
lnd: use first key in keychain.KeyFamilyNodeKey as our nodeID
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.
2018-03-06 16:04:04 -05:00
Olaoluwa Osuntokun
b41222b316
rpc: update RPC server to disallow p2pkh adds, assume segwit for ConfirmedBalance 2018-03-06 16:04:04 -05:00
Olaoluwa Osuntokun
525cca02e2
lnrpc: remove the PUBKEY_HASH adds type, WalletBalance is segwit by default 2018-03-06 16:04:04 -05:00
Olaoluwa Osuntokun
a144018e98
lnwallet: remove p2pkh as an address type, wallet is now pure segwit
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.
2018-03-06 16:04:03 -05:00
Olaoluwa Osuntokun
4b20e805fe
multi: update packages due to recent SignDescriptor and WalletController changes 2018-03-06 16:04:03 -05:00
Olaoluwa Osuntokun
0d1a40fb46
lnwallet: update tests due to recent API changes 2018-03-06 16:04:03 -05:00
Olaoluwa Osuntokun
5b063a0691
lnwallet: modify the way we derive revocation roots to be deterministic
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.
2018-03-06 16:04:02 -05:00
Olaoluwa Osuntokun
a41f00e2d6
lnwallet: update funding flow to utilize keychain.KeyRing
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.
2018-03-06 16:04:02 -05:00
Olaoluwa Osuntokun
fe12c908f8
lnwallet: add an instance of keychain.SecretKeyRing to the Config struct 2018-03-06 16:04:02 -05:00
Olaoluwa Osuntokun
22ee0a7576
lnwallet: update state machine due to channeldb and SignDescriptor changes 2018-03-06 16:04:02 -05:00
Olaoluwa Osuntokun
705661a39e
channeldb: replace raw keys in ChannelConfig with keychain.KeyDescriptor
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.
2018-03-06 16:04:01 -05:00
Olaoluwa Osuntokun
af1fd65655
lnwallet/btcwallet: update Signer implementation to use keychain.KeyDescriptor 2018-03-06 16:04:01 -05:00
Olaoluwa Osuntokun
a0dc06b954
lnwallet: update script_utils and tests due to SignDescriptor API change 2018-03-06 16:04:01 -05:00
Olaoluwa Osuntokun
73dd1536ed
lnwallet: update signdescriptor_test.go due to latest API changes 2018-03-06 16:04:00 -05:00
Olaoluwa Osuntokun
9ccdcaf747
lnwallet: update the SignDescriptor struct to use keychain.KeyDescriptor
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.
2018-03-06 16:04:00 -05:00
Olaoluwa Osuntokun
93280ad60a
lnwallet/btcwallet: update implementation to account for recent API changes
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.
2018-03-06 16:04:00 -05:00
Olaoluwa Osuntokun
6290a520fd
lnwallet/btcwallet: remove pruned interface methods
These methods are no longer a part of the interface. As a result, we
can safely delete them.
2018-03-06 16:04:00 -05:00
Olaoluwa Osuntokun
a26367f3cb
lnwallet: remove NewRawKey and FetchRootKey from the WalletController interface
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.
2018-03-06 16:03:59 -05:00
Olaoluwa Osuntokun
cd068d8888
keychain: add initial set up interface-level tests 2018-03-06 16:03:59 -05:00
Olaoluwa Osuntokun
d6f54b30fc
keychain: add a btcwallet implementation of the KeyRing and SecretKeyRing interfaces 2018-03-06 16:03:59 -05:00
Olaoluwa Osuntokun
aebe7f35dc
keychain: introduce new package for deterministic key derivation + seed
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.
2018-03-06 16:03:58 -05:00
vegardengen
fded72f49d docs: clarify usage of externalip in sample-lnd.conf 2018-03-06 16:03:26 -05:00
Olaoluwa Osuntokun
614e0b3816
Merge pull request #787 from Roasbeef/switch-revenue-stats
lnrpc+htlcswitch+channeldb: add new forwarding log time series and query interface
2018-03-06 15:19:07 -05:00
Olaoluwa Osuntokun
b6713724ed
Merge pull request #781 from Roasbeef/gossiper-skip-validation-if-stale
routing+gossiper: avoid unnecessarily validating sigs for announcement that is "stale"
2018-03-06 15:02:04 -05:00
Olaoluwa Osuntokun
8306273329
cmd/lncli: add new fwdinghistory command 2018-03-06 13:56:13 -05:00
Olaoluwa Osuntokun
643159caff
test: extend testMultiHopPayments to check feereport and forwarding history 2018-03-06 13:56:13 -05:00
Olaoluwa Osuntokun
02852cdc3b
rpc: implement new ForwardingHistory command 2018-03-06 13:56:12 -05:00
Olaoluwa Osuntokun
06c1030999
rpc: populate new day, week, and month fee sums in FeeReport 2018-03-06 13:56:12 -05:00
Olaoluwa Osuntokun
a540003bb9
server: set the FwdingLog attribute in the switch's config 2018-03-06 13:56:12 -05:00
Olaoluwa Osuntokun
36f214f48c
lnrpc: add ForwardingHistory for querying payment circuit time series
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.
2018-03-06 13:56:12 -05:00
Olaoluwa Osuntokun
ff720e1252
lnrpc: extend the FeeReportResponse to include fee revenue sums 2018-03-06 13:56:11 -05:00
Olaoluwa Osuntokun
473dfd115b
htlcswitch: add set of tests for the forwarding log 2018-03-06 13:56:11 -05:00
Olaoluwa Osuntokun
ad522a72c1
htlcswitch: add new ticker in switch to batch log forwarding events
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.
2018-03-06 13:56:11 -05:00
Olaoluwa Osuntokun
6f11fee1a4
htlcswitch: when forwarding htlcs, set the incomingHtlcAmt 2018-03-06 13:56:10 -05:00
Olaoluwa Osuntokun
d377ffafdd
htlcswitch: populate the incoming+outgoing in the payment circuit 2018-03-06 13:56:10 -05:00
Olaoluwa Osuntokun
157e052958
htlcswitch: add the incoming payment amount to the htlcPacket
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.
2018-03-06 13:56:10 -05:00
Olaoluwa Osuntokun
2b8cad2f08
htlcswitch: add incoming+outgoing amounts to the PaymentCircuit
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.
2018-03-06 13:56:09 -05:00
Olaoluwa Osuntokun
744cfd2ce5
channeldb: add a set of initial tests for the ForwardingLog 2018-03-06 13:56:09 -05:00
Olaoluwa Osuntokun
f2cd668bcf
channeldb: add new ForwardingLog storage namespace
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.
2018-03-06 13:56:06 -05:00
Olaoluwa Osuntokun
e7e4cdcf49
discovery: avoid always validating ECDSA sigs by asking router if item is fresh
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.
2018-03-06 13:34:51 -05:00
Olaoluwa Osuntokun
aa0410c90a
routing: add new methods to check the freshness of an edge/node
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.
2018-03-06 13:34:48 -05:00
vegardengen
a1fb22eb8d rpc: properly populate fee field in listpayments 2018-03-06 13:21:03 -05:00
Olaoluwa Osuntokun
61a7556931
Merge pull request #719 from Roasbeef/rpc-seed
lnrpc+walletunlocker: extend wallet creation to allow user generated entropy + entropy restore (BIP 39)
2018-03-05 15:56:41 -05:00
Olaoluwa Osuntokun
3356a370c7
cmd/lncli: extend initial wallet creation with aezeed seed support
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.
2018-03-05 11:07:07 -05:00
Olaoluwa Osuntokun
d8ce90306d
lnwallet/btcwallet: during initial creation catch the case of an existing wallet
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.
2018-03-05 11:07:07 -05:00
Olaoluwa Osuntokun
6289a2fb84
lnd: move seed generation outside wallet to allow for user supplied entropy
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.
2018-03-05 11:07:06 -05:00
Olaoluwa Osuntokun
428693cb6e
walletunlocker: modify service to implement new 2-step wallet creation
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.
2018-03-05 11:07:06 -05:00
Olaoluwa Osuntokun
7f953bf0b9
lnrpc: revamp the WalletUnlocker service to have a two-stage init
In this commit, we revamp the WalletUnlocker service to now have a
two-stage init process.

The first (optional) is for the user instantiating a new lnd instance to
call the GenSeed method with an optional aezeed passphrase. The response
to this will be a freshly generated aezeed mnemonic along with the
original enciphered seed.

The second step will be the actual wallet initaliztion. By separating
this step from seed generation, UI's will be able to ensure that the
user has written down the seed, before proceeding and committing the
seed to the internal wallet. The new method InitWallet accepts a wallet
passphrase, the aezeed mnemonic, and the optional passphrase.
2018-03-05 11:07:01 -05:00
Olaoluwa Osuntokun
294447fe2f
Merge pull request #803 from cfromknecht/glide-crypto-x-version
glide: add explicit version to x/crypto deps
2018-03-05 10:29:33 -05:00