Quit if native bcrypto bindings are missing

[pinheadmz]

This addresses user concern #572
and replaces bcoin-org/bcrypto#9

Test by moving or renaming the build directory in bcrypto which will force bcrypto to use nodejs crypto or proprietary crypto scripts for everything.

This PR throws an Error during handleOpen() that the bindings could not be found unless user explicitly sets NODE_BACKEND=js or NODE_BACKEND=node

[braydonf]

As using JavaScript for many core operations such as secp256k1 verification and signing is really slow. I think it's a good idea to make it clear to the user that C/C++ code is not being used, as it's not practical to run a full node without it. Requiring user action to acknowledge that before proceeding can likely save debugging effort and confusion.

However, I'm not sure that this is the correct place for the check, and seems like it should be part of the build and install. For example, secp256k1-node gives a warning during install if the build fails, and I think there have been specific environment variables to have it error in specific cases.

Also related pull requests:

• Clarify the importance of the gcc/g++ dependency #574
• Add important note about build-essential #573

[tynes]

However, I'm not sure that this is the correct place for the check, and seems like it should be part of the build and install.

Are you suggesting a change to bcrypto or having a postInstall npm script?

I do like the idea of this PR because users should not end up running the JS backend if they did not intend to.

[pinheadmz]

@tynes see bcoin-org/bcrypto#9 (comment)
This check won't be added to bcrypto. I like the idea of a post-install script, but are there scenarios in which the bindings could be installed correctly but then somehow moved or corrupted in some way that the user wouldn't know at run time?

[braydonf]

Okay, yeah there is a case where install may not have been run. Switching nodejs versions may be one of those cases. I ran into this the other day when I saw unusually very slow block verification times, and then npm rebuild fixed it. Would have been good to get a message.

[pinheadmz]

Just noticed this commit in hsd:

handshake-org/hsd@4d7fdf4

Adds the same check as this PR, but in bin/node and quits if the primary hash functions are not built.

[pinheadmz]

So, the idea of putting the backend check in bin makes sense to me -- those files will never be run in a browser like lib/node/node.js where I have the check now. I'm thinking the best approach is to port the commit from hsd to bcoin's bin/node and bin/spvnode and of course change the function to sha256(). Thoughts?

[pinheadmz]

Ok I replaced the commit in this PR with a port of the hsd commit. Just changed blake2b to sha256. Note that secp256k1 is also checked, but I'm not sure how one would be built without the other. (C vs C++ compiler?)

To test:

$ cd bcoin/node_modules/bcrypto
$ mv build build-1
$ bcoin

Bindings for bcrypto were not built.
Please build them before continuing.

[braydonf]

So this has already been helpful, and warnings will appear if switching between nodejs versions and not rebuilding.