Announcing Verus v1.2.2-2 - MANDATORY UPDATE FOR MAINNET UPGRADE TO v1.2.2-2 OR LATER ON VERUS MAINNET BEFORE BLOCK 3000000 (approximately Wed 10 Apr 2024 4 PM UTC, Wed 10 Apr 2024 9 AM PDT) TO REMAIN PROPERLY CONNECTED TO THE VERUS BLOCKCHAIN AS vARRR CONNECTS FOR CROSS-CHAIN OPERATION WITH VERUS ALL BLOCK MINERS AND STAKERS SHOULD UPGRADE ASAP TO INITIATE A PREPARATORY SOFT FORK AND ENSURE THE SMOOTHEST OVERALL NETWORK UPGRADE POSSIBLE
CLI RELEASE:
https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.2-2 GUI RELEASE:
https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.2-2 GUI TESTNET RELEASE:
https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.2-2-testnetvARRR is running smoothly, and all distributions from launch were quickly and properly completed by the chain. It is notarizing properly on its own chain, able to launch its own currencies and able to work with all the currencies already imported from Verus in block 1 to the vARRR chain. As everyone using it has probably noticed, there is still an issue.
A few years ago, a decision was made to incorporate VerusIDs with their attached data into block one instead of without their data, which is the standard procedure for normal VerusID exports. This was done to allow initial oracle behavior to affect block 1, if necessary, which it has never been. This process involves transferring the VerusIDs through JSON during the creation and also the PBaaS chain’s validation of block 1. In this specific launch, one of those VerusIDs contained an unusual VDXF object.
Additionally, there was an issue with the JSON output of this particular type of VDXF object; it deserialized slightly differently than it serialized. Consequently, a VerusID included in the coinbase of vARRR block 1 had slightly different data than the corresponding data on the Verus chain. This discrepancy means that when Verus adheres to the cross-chain protocol for validating the first notarization back to Verus, it rejects vARRR block one due to the data mismatch. This is the same rejection that would safeguard against any kind of change to the specified behavior or distributions. Verus will reject cross-notarization until the Verus network as a whole makes an exception for vARRR, and v1.2.2-2 includes that exception.
Of course, in preparing this release, we also addressed each fundamental point of learning, from deciding not to retain ID data on launch IDs to fixing the JSON serialization of the VDXF object in question. Since the Verus PBaaS networks are networks of people, we need to give some amount of reasonable time, commensurate with the time importance of the change required for everyone to upgrade their nodes and have solid consensus. As a community, we have tools, like decentralized oracles and other network capabilities, which we will employ to allow for a straightforward, non-bootstrap upgrade process, even for those who are unable to upgrade before activation. All that said, WE DO NEED MAXIMUM PARTICIPATION. We have a supportive, large community, and we hope all block validators and most network nodes in general upgrade as soon as possible to help activate a preparatory soft-fork, locking in the vARRR chain for acceptance when the full upgrade activates at block 3,000,000. There are no other changes in v1.2.2-2 besides a resolution for the cross-notarization from vARRR to initiate smooth, and fully functional cross-chain protocols.
Until then, please support the vARRR network and community by merge-mining and continuing to cross-notarize onto the vARRR chain, strengthening its security and keeping it ready to connect when we reach block 3,000,000. Once that block is reached, cross-chain transactions on CLI, desktop, and mobile should proceed as expected, and all funds currently sent and waiting for notarization should arrive.
