Bitcoinjs-lib: Bitcoin Core / WebAssembly

[buu700]

I know that BitcoinJS is a mature and very high-quality library, and I've had a good experience when working with it in the past, so I'm just throwing this idea out there with no expectation that it necessarily makes any sense.

Has any thought been given to selectively replacing the internals with parts of Bitcoin Core compiled to WebAssembly?

Possible benefits:

• Performance (again, just possibly — this may very well not be the case)

• Additional resistance to side channel attacks on the crypto (wasm wouldn't fully mitigate this, but browsers' implementations are expected to be similar to native C compile targets or possibly the JVM in terms of timing characteristics, which would be theoretically superior to standard JS runtimes in that regard)

• Ensured consistency with Bitcoin Core logic and any possible future changes (SegWit, hard fork, etc. (no idea how relevant those particular examples are))

This isn't really a feature request or a suggestion; just mentioning the idea in case there are any problems it would help solve that it hadn't been considered as a solution for.

[dcousens]

Has any thought been given to selectively replacing the internals with parts of Bitcoin Core compiled to WebAssembly?

Typically, readability and reviewability has been the highest priority for this project.

If the above work-flow maintained those priorities, whilst improving the probability of correctness (or at least, consistency), I don't see why it wouldn't be acceptable.

[buu700]

Cool. There are some upcoming emscripten features needed for embedding wasm in JS without breaking compatibility for existing users of the library as explained here, but otherwise using it pretty straightforward.

In my wasm-based libraries like sphincs.js, the pattern I've been using that seems to work well has been to write a small C file that provides function wrappers for any variables and functions that need to be exposed to the JS[1] and then another set of wrappers for those wrappers in JS to handle all the malloc/free boilerplate and provide an interface with only typed array inputs and outputs.

This has been effective for just wrapping a few functions per module, but libsodium.js has a more sophisticated (custom, I believe) build setup that handles autogenerating the boilerplatey JS wrappers based on JSON configuration files.

For BitcoinJS, the way I'd probably handle it would be to create a separate module for the Bitcoin Core wasm wrapper (to avoid complicating the existing bitcoinjs-lib build process with emscripten) — which could be kickstarted by forking something like sphincs.js — and then just import that new module like any other JS library from bitcoinjs-lib.

---

1: C variables can't be accessed from JS without being wrapped as functions, and sometimes it's simpler to handle some wrapping logic on the C side to keep the C-to-JS interface as small as possible. 64-bit integers also can't be directly returned to the JS side, so sometimes a C wrapper is needed just to handle 64-bit -> 32-bit int conversion.

[dcousens]

@buu700 maybe @fanatid could message you how secp256k1 went with emscripten?

[buu700]

Sure, happy to offer any advice or help bounce ideas around for any problems you guys may have run into with that.

[dcousens]

I'm going to close this in favour of https://github.com/bitcoinjs/bitcoinjs-lib/issues/737, as ECDH would be the primary parts we'd look to change if we did.

[bitjson]

For anyone finding this issue now – a WebAssembly version of Secp256k1 is now available. It's about 10x faster than elliptic – you can find benchmarks at the link.