After @yojoe suggestion, we should reserve a byte in RGB Schema for specifying bulletproof implementation which should be used for validating contracts issued under the schema. For now, it has to be set to 0, but in the future, if there wouild be issues discovered in the used implementation and RGB Core library will upgraded with an alternative implementations, a subschemata should be allowed to provide other values specifying the different bulletproof implementation to be used with assets (re-)issued under the subschemata.
While coordinating RGB protocol level upgrades is impossible due to the nature of the client-side-validation, if a bug will be discovered the wallets will be incentivised to upgrade the used versions and issuers will have ability to migrate their assets accordingly. Reserving a byte will allow to maintain binary compatibility of the protocol change.
After @yojoe suggestion, we should reserve a byte in RGB Schema for specifying bulletproof implementation which should be used for validating contracts issued under the schema. For now, it has to be set to 0, but in the future, if there wouild be issues discovered in the used implementation and RGB Core library will upgraded with an alternative implementations, a subschemata should be allowed to provide other values specifying the different bulletproof implementation to be used with assets (re-)issued under the subschemata.
While coordinating RGB protocol level upgrades is impossible due to the nature of the client-side-validation, if a bug will be discovered the wallets will be incentivised to upgrade the used versions and issuers will have ability to migrate their assets accordingly. Reserving a byte will allow to maintain binary compatibility of the protocol change.