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.
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.
Fix a race condition that could cause the app to think that it is still
syncing even after it has completed and as a result being stuck
reporting 100% syncing during the onboarding process.
`startGrpc` can take some time to fully establish and verify that th
connection is set up as we wait for a successful result from a call to
`getInfo`.
Previously, we would send the `lndSyncing` message to the app only after
`startGrpc` was complete. However, if the syncing process had actually
completed before `startGrpc` then we would first notify that syncing had
completed, only to then notify that it had started after it had already
completed.
In this fix, we notify the app of `lndSyncing` immediately after the
wallet has been unlocked.
Fix#525
`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.
Tom Kirkpatrick