This is great. I didn't think we had the resources to compete with bitcoinjs-lib and get features like schnorr signing for ecash txs in a react app.

We should be using this instead of bitcoinjs-lib and BitGo's utxo-lib in Cashtab, token-server, across the ecash stack.

I am not really clear on what went into building this and what it will take to maintain.

Questions

• What comes from rust and what needs to be maintained in rust?
• What work is involved in using the secp256k1 library from the abc monorepo? What is this using now instead?

General points

• Nice that we have a react app so we can prove through CI that the lib will work in a react app and so I can understand how it works. We don't need to launch with this though.
• Could use a README in modules/ecash-lib
• ecash-lib needs unit tests

In D15828#358282, @bytesofman wrote:

We should be using this instead of bitcoinjs-lib and BitGo's utxo-lib in Cashtab, token-server, across the ecash stack.

Yes, that's the goal. I will probably also use it in my apps, and RaiPay could use it too if it wanted SLP V2 or ALP support. RaiPay has Lotus support though, which basically only differs in the txid computation, are you guys cool with adding that function, too?

I am not really clear on what went into building this

Tbh, it took years to come to this design, and it was an evolution:

1. Started with the mini library in SLPAgora, see https://github.com/EyeOfPython/slpagora/blob/master/src/outputs.rs
2. Then morphed that into the bitcoin-cash crate https://github.com/be-cash/bitcoin-cash, which had two versions, has a really powerful TxBuilder, and even has a type-checked Bitcoin Script macro and is compatible with the Iguana debugger (which I both use to this day to write scripts, but it's not really user friendly for normal txs), and I also was able to build it on WebAssembly
3. Then morphed into bitcoinsuite https://github.com/givelotus/bitcoinsuite/, which has been simplified and cleaned up a lot over the bitcoin-cash crate, but still can be used to build the same types of txs, and Chronik uses an even more simplified version of it
4. And now finally ecash-lib, which is a port of the relevant bitcoinsuite stuff, with the ECC stuff bundled into a WASM module.

and what it will take to maintain.

I don't think it will take too much to maintain, there's really only two parts, the WASM and the TypeScript. The WASM may be tricky, since it's not as stable yet. The TypeScript should be no issue, other than a transaction upgrade, it won't require much maintenace. I wrote it in a way which only uses Uint8Array which is a bit harder to read but both very performant and doesn't require any Buffer shims (at the moment).

Questions

• What comes from rust and what needs to be maintained in rust?

derive_pubkey, ecdsa_sign and schnorr_sign, sha256, sha256d, shaRmd160

I also added signRecoverable because it was there, but that's probably better left out for now.

• What work is involved in using the secp256k1 library from the abc monorepo? What is this using now instead?

Currently using my custom fork of the secp256k1 crate, into which I copied the ABC libsecp256k1 library (there's schnorrsig and schnorrabc because BTC and BCH/XEC/... have a different schnorr algo): https://github.com/raipay/secp256k1-abc/

It's around 3 years behind, but the functions seem to work ok. I think eventually the best would be to have our own secp256k1-abc crate in the monorepo that's reasonably well maintained, and backport from the Rust library regularly. Then we can use that to build the WebAssembly, but it also allows Rust developers to use Schnorr signatures etc. on XEC.

• Nice that we have a react app so we can prove through CI that the lib will work in a react app and so I can understand how it works. We don't need to launch with this though.

Yes; this is mostly to showcase and allow to play around with.

• Could use a README in modules/ecash-lib

Yes—and comments in general. It's also lacking all the copyright notices atm.

• ecash-lib needs unit tests

Yes, I think I will need your help here.

It's probably best to setup a regtest system this diff or soon after so we know the txs built are valid on eCash, similar to chronik-client. Not sure what the best approach there is though.

I wrote it in a way which only uses Uint8Array which is a bit harder to read but both very performant and doesn't require any Buffer shims (at the moment).

Nice. The whole node Buffer vs Uint8Array rabbit hole has been a weird sideshow for crypto devs as long as I have been involved anyway. Certainly easier to just use one.

RaiPay has Lotus support though, which basically only differs in the txid computation, are you guys cool with adding that function, too?

I don't think ABC would maintain this going forward. Would have to understand the impact.

happy to help with unit tests and documentation.

I think eventually the best would be to have our own secp256k1-abc crate in the monorepo that's reasonably well maintained, and backport from the Rust library regularly. Then we can use that to build the WebAssembly, but it also allows Rust developers to use Schnorr signatures etc. on XEC.

Would be nice to see a scope of work for this, could see this as a GNC proposal.

From here I think next steps are

1. Get it working as-is
2. Get it tested
3. Get it into the monorepo and published on npm

Then can assess optimizations, secp256k1-abc crate, maintenance etc.

Would you like me to commandeer this or do you want to work through the review? imo will involve dockerizing the build and pulling out create-react app.