BCH Developer Releases New Bitcoin Cash Library Written In Rust Programming Language
Software developer Brenton Gunning recently announced that he has developed a BCH library written in Rust programming language. The newly released product, Rust-BCH 0.1.0, enables BCH developers to work on BCH applications.
I just released rust-bch, a new library for building applications on Bitcoin Cash in Rust. Check it out. https://t.co/SJxNddY5fU
— Brenton Gunning (@brentgunning) November 5, 2018
Rust-BCH 0.1.0 is developed on Rust because of how versatile it is. Fast and low-level, but also very safe and predictable. It's a great fit for many Bitcoin applications. The programming environment for Rust is similar to that of C++.
The newly launched project by Gunning is a library that comprises of protocol messages, address generation, support for mainnet and testnet, transaction signing, script evaluation, wallet key derivation and more.
- P2P protocol messages (construction and serialization)
- Address generation (cashaddr and legacy)
- Transaction signing
- Script evaluation
- Node connections and basic message handling
- Wallet key derivation and mnemonic parsing
- Mainnet and testnet support
- Various Bitcoin primitives
Gunning has differentiated his product from existing Rust libraries like rust-bitcoin, parity-bitcoin, and bitcrust.
The developer also declared his support for SV for the upcoming hardfork. He justified his support by saying the following:
“Why? We all want to scale on chain, and we have different opinions on how to do that, but IMO for the same reason that BTC is irresponsible for hanging their hopes of scaling on the Lightning Network, an unproven technology, it's similarly true for BCH and ABC's roadmap. ABC's plan looks like one option among many to me, and I, like others, still have unresolved doubts going into this fork. To be honest, I'm pretty disappointed that these changes are being forced through for marginal benefits, and this is not the right way to act as stewards of global cash. We need more competition and evidence. Also, I think we generally need a higher bar for consensus changes because they distract the most from global adoption and always risk splitting the chain and community. My point of view is, of course, open to change later, but right now this happens to align with SV.”