secp256k1 no_std/wasm friendly

[vhnatyk]

Seems C library from Rust compiled to WASM is not quite impossible but maybe a better idea to replace with some pure Rust implementation alternative like libsecp256k1-rs

[vhnatyk]

seems the crate we currently use is no_std friendly according to this merged PR

[vhnatyk]

also found origin of the pure rust alternative, though it's not on github

[vhnatyk]

All tests passing including last one test_from_bytes, thanks @omershlo for the suggested fix 👍.
Though #6 is ready to be merged, maybe we should consider keeping no_std and wasm branches separate for some time, since no_std may require further heavy modifications and a current secp256k1 crate is no_std compatible anyway.

[omershlo]

I lost you:

1. replacement of current secp256k1 crate with pure Rust alternative - libsecp256k1 #6 is no_std???
2. replacement of current secp256k1 crate with pure Rust alternative - libsecp256k1 #6 compiles on wasm ? (and how do I try it)
3. I don't understand what two branched you suggest (there's the one with old secp256 lib and the one with new secp256 lib, did you mean these two? )
4. what are the "features" needed for wasm friendly version?

The above is probably a list of stupid questions: If I understand you correctly: #6 is wasm compatible. We want to merge it and start a branch for no_std version? Am I understand you correctly ?

[vhnatyk]

Hi)

1. Current secp256k1 crate got no_std support very recently (10 days ago) - it's wrapper around well established C lib with good performance. Though it's practically not compatible with wasm due to libc

2. replacement of current secp256k1 crate with pure Rust alternative - libsecp256k1 #6 builds on wasm 👍 - but to run actually, there is another PR sitting in my branch cause it's based on top of this unmerged one - and there is info on how to run

3. Actually keeping support for both no_std and wasm in a single branch via conditional compilation may be a bit tedious. There are few more duplicating crates to be removed etc - the issue is flash memory size, RAM usage etc - while with that delayed PR we are fine for wasm already. Maybe we should try to keep two separate branches for no_std and wasm(or make wasm master) - as probably still a huge amount of work ahead for bare metal devices

4. Please check the draft PR - as it has only delta between this replacement of current secp256k1 crate with pure Rust alternative - libsecp256k1 #6 and clearly shows code that makes it run on wasm

At the moment I tend to find more benefits from pure rust crate in this PR - main concern was the performance, now we know is ok in release, and result compiled file size is a lot smaller. Current rust-secp256k1 C lib is ~500kb almost uncompressable. Pure Rust libsecp256k1 is smaller.

[Sintayew4]

#4