Start of v0.11 development cycle for non-consensus code

[dr-orlovsky]

I plan to start working on RGB std lib/wallet version 0.11 (NB: not consensus or RGB Core v0.11, they are staying 0.10.x!)

These are improvements to the wallet management cycle (like making electrum optional), improvements to the validation performance etc. Some will be API breaking - but again, no consensus or interface breaks, just the compilation (change in auxiliary function arguments etc).

We will have over time v0.11, 0.12, 0.13 etc of the RGB standard and wallet libraries - but they are expected to use the current version's RGB Core and other consensus libs. If down the road we will have backwards-compatible consensus changes in consensus libs (like the addition of new op codes to VM, or bulletproofs library) we will mark that RGB consensus version v0.11 etc - but please pay attention, to the numbering of versions of RGB consensus and std/wallet libs may start not to match in the future (for instance, RGB wallet may be v0.12 using RGB consensus libs of v0.10).

Right now to start the new developing cycle for v0.11 non-consensus libraries I am going to:

• release rgb-contracts crate v0.10.0 (before we had just v0.10.0-rc.X);
• yank all past versions of all crates in set 0.10.x which are incompatible with this final release of RGB v0.10.

[zoedberg]

ACK

[fedsten]

ACK

[cryptoquick]

ACK

[cedricfung]

I see both the rgb and rgb-core repos are tagged 0.11, does this mean the consensus changes are also happening?

[dr-orlovsky]

Yes, we had to make them since it became apparent from the Blockstream review that we used their secp256k1-zpk library for confidential commitments in incorrect way.