Handle the case were the Neutrino backend BTCd node is still
synchronising the blockchain as LND is not able to start syncing
until the BTCd node that it is connected to is fully synced.
Fetch the current block height from multiple block explorers early on in
the sync process. This ensures that we get the correct block height in
the case where our BTCd node is still mid way through syncing. Do this
in the main process rather than in the render process.
When matching log lines, switch on the regex match rather than an
excerpt, so that there are never any false positives.
Note this allows conditional assignment within parens as well.
Determine the current block height directly from the lnd log output and
pass the data into the app as soon as we have it. Do not call out to
block explorers if we don't need to.
`main.dev.js` was hard to follow and understand the code flow. It housed
code to handle quite a few distinct things. This is a fairly substantial
refactor of the application startup code in which we:
A new `Neutrino` class has been created with 2 public methods. `start`
and `stop`. `start` will launch a new `lnd` process whilst `stop` will
stop it. This class extends the `EventEmitter` class and emits the
following events based on activity detected from the lnd log output.
- `grpc-proxy-started` - gRPC started
- `wallet-opened` Wallet opened
- `fully-synced` - lnd is all caught up to the blockchain
- `got-block-height` - got updated block height
A new `ZapController` class has been created which houses all of the
logic for intraprocess communication between the main and renderer
processes.
Previously we had several `setInterval` loops that were checking every
second to see if the application status has changed and trigging the
appropriate action if so. This was pretty hard to follow has been
replaced here with more extensive use of promises. This enables us to
act instantly to relevant changes rather than waiting up to 1 second
for the next interval to fire.
Now, the only stuff that lives in `main.dev.js` now is the top level
`app` listeners, which calls out the other parts mentioned above to
bootstrap the application.
This enables easy access to all lnd settings for development, and is a step
toward relying on an external configuration file that will be accessible to
users for whom the code is not.
Among other things, this makes no-console an error rather than a warning.
https://eslint.org/docs/rules/no-console
Given that we now have a proper logging facility, good to prevent incidental
introduction in the future.
Move rpc.proto into the resources directory along with all of the other
external resources.
Fix up the resource paths to reference external resources correctly
depending on wether the app is being run locally or from a release.
Only one of these files was being used, and they were going out of step
relative to one another.
Put rpc.proto in the resources directory for consistency with other
vendored resources, i.e. the lnd binary
Updated the def from:
https://github.com/lightningnetwork/lnd/blob/master/lnrpc/rpc.proto
The wallet password is defined as `bytes` in the rpc.proto spec and we are
passing it as a string, resulting in an incorrect password being set on a
new wallet and an inability to unlock an existing wallet.
Convert the wallet password to a Buffer before passing to `initWallet` and
`unlockWallet`, which is the default data type used to represent bytes in
the node grpc client. This is sures that the password is passed correctly
to lnd.
Fix#400
Use grpc.credentials.combineChannelCredentials to combine the ssl
credentials with the macaroons when initializing the lnd rcp client.
This avoids the need to pass the macaroon metadata throughout the
codebase.
Tom Kirkpatrick
Ben Woosley
Jack Mallers
Tom Kirkpatrick