Version v0.9

[dr-orlovsky]

We need to merge this into the master in order to do a final v0.9.0 release after RC1 is tested

[dr-orlovsky]

@cryptoquick I am not tracking rand version, so its update is a coincidence. Do you have any idea what requires rand 0.7 and how that requirement can be raised?

[cryptoquick]

@cryptoquick I am not tracking rand version, so its update is a coincidence. Do you have any idea what requires rand 0.7 and how that requirement can be raised?

Looks like it's used by a version of ed25519-dalek, according to the output of cargo tree:

cargo tree -i -p rand@0.7.3
rand v0.7.3
└── ed25519-dalek v1.0.1
    └── strict_encoding v0.8.1
        ├── aluvm v0.7.0
        │   └── rgb-core v0.8.0 (/home/hunter/Projects/bitcoinhackers/rgb-org/rgb-core)
        ├── bitcoin_hd v0.8.1
        │   ├── bitcoin_onchain v0.8.1
        │   │   ├── bp-seals v0.8.0
        │   │   │   └── bp-core v0.8.0
        │   │   │       └── rgb-core v0.8.0 (/home/hunter/Projects/bitcoinhackers/rgb-org/rgb-core)
        │   │   ├── descriptor-wallet v0.8.2
        │   │   │   └── rgb-core v0.8.0 (/home/hunter/Projects/bitcoinhackers/rgb-org/rgb-core)
        │   │   └── psbt v0.8.4
        │   │       └── descriptor-wallet v0.8.2 (*)
        │   ├── descriptor-wallet v0.8.2 (*)
        │   ├── descriptors v0.8.0
        │   │   ├── bitcoin_onchain v0.8.1 (*)
        │   │   └── psbt v0.8.4 (*)
        │   └── psbt v0.8.4 (*)
        ├── bitcoin_onchain v0.8.1 (*)
        ├── bitcoin_scripts v0.8.2
        │   ├── bp-dbc v0.8.0
        │   │   ├── bp-core v0.8.0 (*)
        │   │   └── bp-seals v0.8.0 (*)
        │   ├── descriptor-wallet v0.8.2 (*)
        │   ├── descriptors v0.8.0 (*)
        │   ├── lightning_encoding v0.8.0
        │   │   └── lnpbp_chain v0.8.0
        │   │       └── lnpbp v0.8.0
        │   │           └── rgb-core v0.8.0 (/home/hunter/Projects/bitcoinhackers/rgb-org/rgb-core)
        │   └── psbt v0.8.4 (*)
        ├── bp-core v0.8.0 (*)
        ├── bp-dbc v0.8.0 (*)
        ├── bp-seals v0.8.0 (*)
        ├── commit_verify v0.8.0
        │   ├── bp-core v0.8.0 (*)
        │   ├── bp-dbc v0.8.0 (*)
        │   ├── bp-seals v0.8.0 (*)
        │   ├── psbt v0.8.4 (*)
        │   └── rgb-core v0.8.0 (/home/hunter/Projects/bitcoinhackers/rgb-org/rgb-core)
        ├── descriptor-wallet v0.8.2 (*)
        ├── descriptors v0.8.0 (*)
        ├── lightning_encoding v0.8.0 (*)
        ├── lnpbp_bech32 v0.8.0
        │   ├── bp-seals v0.8.0 (*)
        │   └── lnpbp v0.8.0 (*)
        ├── lnpbp_chain v0.8.0 (*)
        ├── psbt v0.8.4 (*)
        ├── rgb-core v0.8.0 (/home/hunter/Projects/bitcoinhackers/rgb-org/rgb-core)
        ├── slip132 v0.8.0
        │   ├── bitcoin_hd v0.8.1 (*)
        │   └── descriptor-wallet v0.8.2 (*)
        ├── stens v0.7.1
        │   └── rgb-core v0.8.0 (/home/hunter/Projects/bitcoinhackers/rgb-org/rgb-core)
        └── strict_encoding_test v0.8.0
            [dev-dependencies]
            └── rgb-core v0.8.0 (/home/hunter/Projects/bitcoinhackers/rgb-org/rgb-core)

Unfortunately, the dalek crates are unmaintained and annoying to replace. I remember zebra being somewhat good, though: https://crates.io/crates/ed25519-zebra

[dr-orlovsky]

@cryptoquick I see that zebra depends on dalek as well. I had used ed25519-compact recently and it is very small, zero dependencies and well-maintained. Let's switch to it. I think I can do it in v0.9, and for that reason we can go RC2 if needed

[dr-orlovsky]

I actually do not think we need ed25519 in LNP/BP stack at all. It is a legacy from the time RGB had specific state in the schema, where one of the options were adwards keys and sigs for smart contracts which will use them (like PGP-type RGB22 contracts). Today, with typed data, that is not used anymore. Another use was support by AluVM, again for the contracts needing them - but that doesn't need to get into strict encoding and expose rand. Finally, it is used in identity apps like lnpbp_identity, but that is not in the RGB upstream dependencies.

[dr-orlovsky]

RC2 is out with rand bumped to 0.8.5.

@cryptoquick pls let me know does this unlock WASM build. I'd really like it to happen in v0.9. Regarding AluVM, I was not able to get rid of dalek dependency there (requires rewrite of all ed25519 operation implementation), but since we do not enable that instruction set in RGB Core anyway, it was not a problem for v0.9 - dalek dependency does not propagate here. I'll deal with dalek in AluVM in v0.10, and than we will enable that curve in RGB contracts.

[cryptoquick]

Oh wow, that a all makes sense. Do you think you'll depend on ed25519-compact in AluVM for RGB22?

I'll be sure to test out WASM builds when we go to upgrade bitmask-core to use 0.9.

[dr-orlovsky]

Do you think you'll depend on ed25519-compact in AluVM for RGB22?

Yes

I'll be sure to test out WASM builds when we go to upgrade bitmask-core to use 0.9.

Do you depend there on RGB Node - or on RGB Core directly?

[cryptoquick]

We only depend on rgb-std and rgb-core. We also depend on rgb20, but I think that's scheduled to be deprecated?

See: https://github.com/diba-io/bitmask-core/blob/42dc3fad86c8a2b0a8d290950744fb10c07742b0/Cargo.toml#L89-L94

[dr-orlovsky]

Cool. And yes, rgb20 is scheduled to be deprecated, but this can happen only in v0.10 when interfaces will arrive