secp256k1-node icon indicating copy to clipboard operation
secp256k1-node copied to clipboard

Consider using WebAssembly for the browser implementation

Open kripod opened this issue 7 years ago • 6 comments

Related article: https://blog.bitjson.com/just-released-webassembly-version-of-secp256k1-10x-faster-than-javascript-eb3cebe4d411

kripod avatar Jun 05 '18 08:06 kripod

@kripod what is the route for detecting support for that?

dcousens avatar Jun 05 '18 09:06 dcousens

@dcousens It isn’t trivial, but I found the following answer on StackOverflow: https://stackoverflow.com/a/47880734

kripod avatar Jun 05 '18 09:06 kripod

@bitjson do you encourage users to compile their own WASM? What is the release process for inclusion in a library like this (or others).

dcousens avatar Jun 05 '18 09:06 dcousens

I had seen this article yesterday, performance make impression. Not sure what we should do here, I'd like that users compiled WASM themselves (on same reason why I removed prebuild bindings). Also looks like we need elliptic in any case, because sometimes WASM can be not supported by old browsers.

fanatid avatar Jun 05 '18 14:06 fanatid

@dcousens I don't think it's particularly necessary for users to compile their own. If users are already trusting the javascript they're getting from NPM, they might as well trust the WebAssembly too. If not, users should audit both themselves, and part of doing that would be to run the WASM compilation step (or check that entities they trust have signed it). Not a new problem in the Node.js space though.

For now, I've opted to avoid even PGP signing anything, since I'd rather people not trust me at all. (In the future, I'm hoping to use something more definitive than PGP, like BitAuth, then I might start signing things. 😄)

bitjson avatar Jun 05 '18 14:06 bitjson

WebAssembly + n-api addon in fanatid/fcrypto

fanatid avatar Dec 15 '19 14:12 fanatid