Increase portability for v0.10

[dr-orlovsky]

I plan to dramatically increase portability of the new release, including support for WASM builds, by reducing number of dependencies - and getting rid of all C-libraries downstream. Specifically, I plan to:

1. Remove any dependencies on rust-miniscript, since this consensus library must not touch anything wallet-related
2. Remove secp256k1 dependency, since this library doesn't do anything to public or private keys outside of bulletproffs/pedenrsen commitments, which anyway are not a part of secp256k1
3. In order to do that we would also need to abandon rust-bitcoin library (which requires secp256k1), but this is nice, since again, only a very few structures from rust-bitcoin are used in RGB core and in single-use-seals and they can be replaced with local vatiants. We do not use transactions, keys etc - just txids and output numbers, which is highly trivial and for sure shouldn't require rust-bitcoin dependency tree.
4. We also can get rid of descriptor-wallet dependency here, since again RGB Core has nothing to do with any wallet-level stuff.
5. I plan to revisit and remove any other possible dependencies on lightning-related and generic things, which shouldn't belong here;
6. The most problematic part is to remove secp256k1-zkp fork which requires C lib, breaks WASM compillation and is needed for bulletproofs. But I think this is also possible and I am opening a separate issue to discuss on the best way of achieving that (UPD: https://github.com/RGB-WG/rgb-core/issues/130).

All these changes should significantly speed up compilation time - and also allow us to have a good progress toward ossification and v1.0 release: without rust-bitcoin family of dependencies we would not need to re-factor everything each new release and do a new version. RGB Core would become pure consensus library not requiring regular releases - and the release cycle of RGB standard library, RGB Node and LN-/wallet-related stuff can become fully independent (and much shorter) with that. I.e. version v0.10 of RGB Core should become the last version for at least this year (unless a major bugs are discovered); after which we can move to v1.0 of it.

[cryptoquick]

I think this is a good decision; since we're using BDK for wallet stuff, it's often difficult to upgrade RGB due to the mutual rust-bitcoin dependency. All three had to be updated at once.

As for bulletproofs, have you received any updates from the Blockstream folks? Is there anything @fedsten or @Gigi3D at DIBA can do to help that along from the business side?

[dr-orlovsky]

This also would help RGB Core to become no-std and be able to run on hardware wallets.

[dr-orlovsky]

My expectation that the proposal would allow to go from this list of consensus-level libraries (plus their upstream dependencies):

• secp256k1 (C-based)
• bitcoin_hashes
• rust-bitcoin
• rust-miniscript
• rust-electrum
• amplify
• lnpbp_secp256k1zkp (C-based, non-WASM)
• strict_encoding
• stens
• aluvm
• commit_verify
• single_use_seals
• client_side_validation
• bitcoin_blockchain
• bitcoin_scripts
• bitcoin_hd
• descriptors
• bitcoin_online
• psbt
• descriptor-wallet
• lnpbp_bech32
• lnpbp_chain
• bp-dbc
• bp-seals
• rgb-core

to this list:

• amplify
• strict_encoding
• strict_types
• aluvm
• commit_verify
• single_use_seals
• bitcoin_scripts
• bp-dbc
• bp-seals
• rgb-core

25 vs 10 libraries; and in 25 libs there were 6 which are not maintained by LNP/BP + 2 C libs, including one WASM-compatible. Wit this proposal we are getting rid of all those external legacy

[cryptoquick]

Much better! This will also streamline review, publishing, and a security audit, in addition to the portability improvements.

[cryptoquick]

Also, I Just ran into a case today where I could've made use of this, since there are data structures returned from RGB like rgb_std::Disclosure that we can't really decode in WASM right now, see:

https://github.com/diba-io/bitmask-core/blob/7bbed2715c4a3d77158dbf68ae7cdef59cd54752/src/data/structs.rs#L1-L13

So we basically have to return double-encoded (unparsable) JSON, which is ugly and useless.

[dr-orlovsky]

where I could've made use of this

Sorry, not clear, use of what?

[cryptoquick]

where I could've made use of this

Sorry, not clear, use of what?

RGB structs that can compile to WASM so I can deserialize them on the frontend.

[dr-orlovsky]

But why some of RGB structs can't compile to wasm? Because they depend/contain bulletproof data? Or any other reason?

[cryptoquick]

The crates I get them from (like rgb_std) depend on stuff like Amplify; I forget if you were able to fix that, but if you did, maybe the latest version isn't being used by the 0.9 rc crates we're using.

[dr-orlovsky]

Amplify was fixed, but probably v0.9 are not on the latest version, yes.