Numbers design decision

[GregTheGreek]

As per our discussion on 08/02/19 with @JonathanLorimer @wemeetagain @GregTheGreek @ansermino

We have decided to temporarily take focus off of fixed-size-number-ts and explore using big numbers.

We could utilize javascript number api for everything under 2**53 - 1 (i.e uint8, uint16, ....).

Any notes I missed please add them.

[tynes]

Node.js LTS has added BigInts [1], they are seeing some usage in Handshake [2]. Might be useful for the BLS Signatures

[1] https://developers.google.com/web/updates/2018/05/bigint
[2] https://github.com/handshake-org/goosig/blob/master/lib/js/bigmath.js

[wemeetagain]

@tynes
Thanks for the heads up!
I think we'd love to use native BigInts if possible, though it may take us a while to migrate in that direction. Some thoughts in no particular order:

• Our version of typescript doesn't support native Bigints (we need to upgrade to 3.3)
• We're thinking of using babel (and https://babeljs.io/docs/en/babel-plugin-syntax-bigint) to aid with building for non-BigInt-supporting environments
• We may not need BigInts in most cases: The integer debate ethereum/consensus-specs#626 (comment)
• We just had a team discussion today, some notes here, and we decided to hold off on messing with our bigint implementation for now, at least until the spec settles down a bit more.
• For bls signatures, we're leaning toward using https://github.com/herumi/mcl-wasm , which should take care of most of the heavy lifting using wasm, take a look at https://github.com/chainsafesystems/bls-js , should be really neat once it all works

[tynes]

Thanks for sharing all of this! We have a bunch of good JS tools over here at bcoin/handshake and I'm rooting for y'all and looking for ways to collaborate when it makes sense