Veruscoin Announcements pinned «Announcing Verus v1.2.2-3 - MANDATORY UPDATE FOR vARRR MAINNET, HIGHLY RECOMMENDED FOR ALL SERVICE NODE OPERATORS AND VERUS MAINNET CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.2-3 GUI RELEASE: https://github.com/VerusCoin/Verus-…»
Announcing Verus v1.2.2-4 - MANDATORY UPDATE FOR vARRR MAINNET SUPPORT BEFORE vARRR BLOCK 67000 (in approximately 1 month) OR EARLIER IF DECIDED BY THE vARRR COMMUNITY. NEW PBaaS CHAINS SHOULD LAUNCH USING v1.2.2-4
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.2-4
GUI RELEASE: https://github.com/.../Verus-Desktop/releases/tag/v1.2.2-4
GUI TESTNET RELEASE: https://github.com/.../Veru.../releases/tag/v1.2.2-4-testnet
MANDATORY UPDATE FOR CONTINUED VERUS TESTNET USAGE
CRITICAL UPDATE FOR VERUS MINING AND STAKING NODES
A small number of recently exported VerusIDs from Verus to vARRR exposed an issue that is not a security issue but has a potential unintended consequence for some users. Due to the way that VerusID locks and unlocks work, VerusIDs that have been locked, then unlocked, then exported to vARRR from Verus may end up locked on vARRR until a block height very far in the future that is the block where it actually unlocked on Verus. This happened to 3 IDs that were exported.
v1.2.2-4 will check in the sendcurrency command when a VerusID is exported to another chain if the timelock is set as an absolute timelock (specific to chain), or if the timelock is non-zero on an unlocked ID. If so, sendcurrency will throw an error along with a specific command needed to zero the value before exporting the ID.
At block 67000 on vARRR, v1.2.2-4 and all PBaaS chains will begin clearing this condition as part of importing an ID. After that time, someone in the community may make pull request to remove the warning and failure on sendcurrency, which will no longer have a potential unintended consequence.
v1.2.2-4 Fixes an issue with Verus Desktop on Windows, which could sometimes result in the Verus daemon seeming to be closed when it was not. We believe this may have resulted in the need for some Windows users to bootstrap, even when Windows Update hadn’t directly rebooted their system.
v1.2.2-4 Enables adding VRSC as a vARRR currency or vARRR as a Verus currency in Verus Desktop and has UI improvements for defi functions
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.2-4
GUI RELEASE: https://github.com/.../Verus-Desktop/releases/tag/v1.2.2-4
GUI TESTNET RELEASE: https://github.com/.../Veru.../releases/tag/v1.2.2-4-testnet
MANDATORY UPDATE FOR CONTINUED VERUS TESTNET USAGE
CRITICAL UPDATE FOR VERUS MINING AND STAKING NODES
A small number of recently exported VerusIDs from Verus to vARRR exposed an issue that is not a security issue but has a potential unintended consequence for some users. Due to the way that VerusID locks and unlocks work, VerusIDs that have been locked, then unlocked, then exported to vARRR from Verus may end up locked on vARRR until a block height very far in the future that is the block where it actually unlocked on Verus. This happened to 3 IDs that were exported.
v1.2.2-4 will check in the sendcurrency command when a VerusID is exported to another chain if the timelock is set as an absolute timelock (specific to chain), or if the timelock is non-zero on an unlocked ID. If so, sendcurrency will throw an error along with a specific command needed to zero the value before exporting the ID.
At block 67000 on vARRR, v1.2.2-4 and all PBaaS chains will begin clearing this condition as part of importing an ID. After that time, someone in the community may make pull request to remove the warning and failure on sendcurrency, which will no longer have a potential unintended consequence.
v1.2.2-4 Fixes an issue with Verus Desktop on Windows, which could sometimes result in the Verus daemon seeming to be closed when it was not. We believe this may have resulted in the need for some Windows users to bootstrap, even when Windows Update hadn’t directly rebooted their system.
v1.2.2-4 Enables adding VRSC as a vARRR currency or vARRR as a Verus currency in Verus Desktop and has UI improvements for defi functions
GitHub
Release v1.2.2-4 · VerusCoin/VerusCoin
Announcing Verus v1.2.2-4 - MANDATORY UPDATE FOR vARRR MAINNET SUPPORT BEFORE vARRR BLOCK 67000 (in approximately 1 month) OR EARLIER IF DECIDED BY THE vARRR COMMUNITY. NEW PBaaS CHAINS SHOULD LAUN...
Veruscoin Announcements pinned «Announcing Verus v1.2.2-4 - MANDATORY UPDATE FOR vARRR MAINNET SUPPORT BEFORE vARRR BLOCK 67000 (in approximately 1 month) OR EARLIER IF DECIDED BY THE vARRR COMMUNITY. NEW PBaaS CHAINS SHOULD LAUNCH USING v1.2.2-4 CLI RELEASE: https://github.com/VerusCoi…»
Announcing Verus Mobile v1.0.12 - MANDATORY UPDATE FOR THOSE WANTING TO CONVERT OR SEND DAI CROSS-CHAIN FROM ETHEREUM TO VERUS DAI ETH-VRSC Transactions:
Android App is available on the play store at: https://play.google.com/store/apps/details?id=org.autonomoussoftwarefoundation.verusmobile.android&hl=en&gl=US
iOS App Available on the Apple App Store (version 1.0.12 still pending): https://apps.apple.com/us/app/verus-mobile/id6447361908
Github Builds for Android: https://github.com/VerusCoin/Verus-Mobile/releases
The last 2 versions of Verus Mobile had an issue where it would often underestimate the GAS required for sending DAI to Verus. This usually leads to DAI transfers via mobile from the Ethereum network sent across the Etherum-Verus bridge to be rejected, while the ETH network still burns up the calculated fee.
This is due to an ETH requirement that the fee provided actually must exceed the fee that will be used. This update fixes that issue by increasing the calculated estimate to an amount above that which will actually be used. Do not send DAI across the Verus-Ethereum bridge with Verus Mobile (you can use the bridge website instead) until you upgrade, or you risk losing the ETH fee and having your transaction reverted.
End to current TestFlight App (Verus Wallet): Due to Apple App Store policy, the TestFlight version of Verus Mobile (called Verus Wallet) will no longer be updated (beyond 1.0.11). If you have any keys controlled by this wallet, make sure to back them up or move them to a release of Verus Mobile or another wallet before the current version expires. A new TestFlight version of the app will be released in the coming future, but it will be considered a different app by iOS and data will not be transferred. It is recommended that you import your iOS TestFlight app data into the App Store version for now and use the App Store app instead.
The App Store app remains unaffected by this and is kept up to date. This also means in order to send DAI across the bridge, please use the Apple App Store app. Android builds remain unaffected.
New Interface and Conversion Suggestions: As of 1.0.11, some of you may have noticed a slightly different interface on the wallet overview pages for currencies. This should increase performance with multiple wallet cards, and increase usability. Also, suggested paths for conversion on PBaaS chains, like vARRR, should be accurate now and show all possible options.
Android App is available on the play store at: https://play.google.com/store/apps/details?id=org.autonomoussoftwarefoundation.verusmobile.android&hl=en&gl=US
iOS App Available on the Apple App Store (version 1.0.12 still pending): https://apps.apple.com/us/app/verus-mobile/id6447361908
Github Builds for Android: https://github.com/VerusCoin/Verus-Mobile/releases
The last 2 versions of Verus Mobile had an issue where it would often underestimate the GAS required for sending DAI to Verus. This usually leads to DAI transfers via mobile from the Ethereum network sent across the Etherum-Verus bridge to be rejected, while the ETH network still burns up the calculated fee.
This is due to an ETH requirement that the fee provided actually must exceed the fee that will be used. This update fixes that issue by increasing the calculated estimate to an amount above that which will actually be used. Do not send DAI across the Verus-Ethereum bridge with Verus Mobile (you can use the bridge website instead) until you upgrade, or you risk losing the ETH fee and having your transaction reverted.
End to current TestFlight App (Verus Wallet): Due to Apple App Store policy, the TestFlight version of Verus Mobile (called Verus Wallet) will no longer be updated (beyond 1.0.11). If you have any keys controlled by this wallet, make sure to back them up or move them to a release of Verus Mobile or another wallet before the current version expires. A new TestFlight version of the app will be released in the coming future, but it will be considered a different app by iOS and data will not be transferred. It is recommended that you import your iOS TestFlight app data into the App Store version for now and use the App Store app instead.
The App Store app remains unaffected by this and is kept up to date. This also means in order to send DAI across the bridge, please use the Apple App Store app. Android builds remain unaffected.
New Interface and Conversion Suggestions: As of 1.0.11, some of you may have noticed a slightly different interface on the wallet overview pages for currencies. This should increase performance with multiple wallet cards, and increase usability. Also, suggested paths for conversion on PBaaS chains, like vARRR, should be accurate now and show all possible options.
Google Play
Verus Mobile - Apps on Google Play
Join the Internet of Value
Announcing Verus v1.2.2-5
UPDATE MAINNET NODES BY:
– VERUS MAINNET BEFORE BLOCK 3050000
– vARRR MAINNET BEFORE vARRR BLOCK 67000, SAME AS PRIOR RELEASE
NEW PBaaS CHAINS SHOULD LAUNCH USING v1.2.2-5 OR LATER
CRITICAL UPDATE ASAP FOR ALL VALIDATORS
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.2-5
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.2-5
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.2-5-testnet
During the launch of Kaiju, a transaction was accepted by the network that requested a conversion from a currency not in the Kaiju basket to Kaiju. In the checks where it was accepted, it was marked for refund, and although we saw it before launch, we expected it to proceed normally and refund.
When the Kaiju launch block came, an additional check for that case that was present on import considered it an error, and instead of allowing it to pass, refused to consider that import valid, blocking completion of the launch protocol. When v1.2.2-5 represents the majority of the network validators and activates, validators will stop preventing that import from being processed, Kaiju launch protocol will complete, the offending transfer will be refunded, and the Kaiju basket will then operate as usual. Please update as soon as possible to clear the way for normal operation of Kaiju or any future currency launch, preventing any such issue in the future on all chains.
UPDATE MAINNET NODES BY:
– VERUS MAINNET BEFORE BLOCK 3050000
– vARRR MAINNET BEFORE vARRR BLOCK 67000, SAME AS PRIOR RELEASE
NEW PBaaS CHAINS SHOULD LAUNCH USING v1.2.2-5 OR LATER
CRITICAL UPDATE ASAP FOR ALL VALIDATORS
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.2-5
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.2-5
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.2-5-testnet
During the launch of Kaiju, a transaction was accepted by the network that requested a conversion from a currency not in the Kaiju basket to Kaiju. In the checks where it was accepted, it was marked for refund, and although we saw it before launch, we expected it to proceed normally and refund.
When the Kaiju launch block came, an additional check for that case that was present on import considered it an error, and instead of allowing it to pass, refused to consider that import valid, blocking completion of the launch protocol. When v1.2.2-5 represents the majority of the network validators and activates, validators will stop preventing that import from being processed, Kaiju launch protocol will complete, the offending transfer will be refunded, and the Kaiju basket will then operate as usual. Please update as soon as possible to clear the way for normal operation of Kaiju or any future currency launch, preventing any such issue in the future on all chains.
GitHub
Release v1.2.2-5 · VerusCoin/VerusCoin
Announcing Verus v1.2.2-5
UPDATE MAINNET NODES BY:
VERUS MAINNET BEFORE BLOCK 3050000
vARRR MAINNET BEFORE vARRR BLOCK 67000, SAME AS PRIOR RELEASE
NEW PBaaS CHAINS SHOULD LAUNCH USING v1.2.2-5 OR...
UPDATE MAINNET NODES BY:
VERUS MAINNET BEFORE BLOCK 3050000
vARRR MAINNET BEFORE vARRR BLOCK 67000, SAME AS PRIOR RELEASE
NEW PBaaS CHAINS SHOULD LAUNCH USING v1.2.2-5 OR...
Veruscoin Announcements pinned «Announcing Verus v1.2.2-5 UPDATE MAINNET NODES BY: – VERUS MAINNET BEFORE BLOCK 3050000 – vARRR MAINNET BEFORE vARRR BLOCK 67000, SAME AS PRIOR RELEASE NEW PBaaS CHAINS SHOULD LAUNCH USING v1.2.2-5 OR LATER CRITICAL UPDATE ASAP FOR ALL VALIDATORS CLI RELEASE:…»
From verus team regarding minor fork
We have reports of a minor fork of 11 MH on the network that is not being notarized to Ethereum and will not cause any problem on the decentralized connection, but could potentially cause issues for centralized services that may have gotten onto that fork. Please check your nodes or native wallets and confirm that you are on the same network as the explorer. We are continuing to look into the issue, but we do not see any forks yet on servers that have not reported.
After investigation, we have determined that although, just after the announcement of v1.2.2-5, they were notified via github, according to their required process, many (or most) of the KMD notaries did not upgrade to v1.2.2-5, nor did they communicate or request additional time to do so. As a result, we did not extend the upgrade block height with an oracle notification. Shortly after the upgrade activated, the KMD notaries began notarizing a fork caused by them being unable to follow the network upgrade and also being connected to a small amount of hash + at least 3 million VRSC of staking power, also not upgraded. As a result, they began notarizing a very small fork that could have been followed by an updated node, if that updated node was connected to a subnetwork consisting of only the Komodo notaries and older versions mining and staking. Fortunately, the Verus protocol will not follow the Komodo notaries if they disagree with the VIP notarizations made by the most powerful chain into ETH, ensuring that they can add value if consistent, but that the ETH connection always tracks the most powerful & witnessed chain in any potential situation that might create a fork. Once the v1.2.2-4 KMD notary nodes saw the post upgrade blocks, they would have rejected those blocks and banned the nodes sending them, creating an isolated network, which they continued to notarize. From our current analysis, there is no harm done to the Verus network, and there were a minimal number of nodes that ended up following the fork. We have obtained access to the fork and stopped it with an Oracle update, ensuring that anyone who was not intentionally trying to ignore oracle updates on that fork can not be harmed by any potential activity. At this time, the Verus network is completely fine and being finalized by Verus VIP against the Ethereum network. While it is possible for the Komodo notaries to fix their situation by upgrading, the network is fine whether they do or not.
We have reports of a minor fork of 11 MH on the network that is not being notarized to Ethereum and will not cause any problem on the decentralized connection, but could potentially cause issues for centralized services that may have gotten onto that fork. Please check your nodes or native wallets and confirm that you are on the same network as the explorer. We are continuing to look into the issue, but we do not see any forks yet on servers that have not reported.
After investigation, we have determined that although, just after the announcement of v1.2.2-5, they were notified via github, according to their required process, many (or most) of the KMD notaries did not upgrade to v1.2.2-5, nor did they communicate or request additional time to do so. As a result, we did not extend the upgrade block height with an oracle notification. Shortly after the upgrade activated, the KMD notaries began notarizing a fork caused by them being unable to follow the network upgrade and also being connected to a small amount of hash + at least 3 million VRSC of staking power, also not upgraded. As a result, they began notarizing a very small fork that could have been followed by an updated node, if that updated node was connected to a subnetwork consisting of only the Komodo notaries and older versions mining and staking. Fortunately, the Verus protocol will not follow the Komodo notaries if they disagree with the VIP notarizations made by the most powerful chain into ETH, ensuring that they can add value if consistent, but that the ETH connection always tracks the most powerful & witnessed chain in any potential situation that might create a fork. Once the v1.2.2-4 KMD notary nodes saw the post upgrade blocks, they would have rejected those blocks and banned the nodes sending them, creating an isolated network, which they continued to notarize. From our current analysis, there is no harm done to the Verus network, and there were a minimal number of nodes that ended up following the fork. We have obtained access to the fork and stopped it with an Oracle update, ensuring that anyone who was not intentionally trying to ignore oracle updates on that fork can not be harmed by any potential activity. At this time, the Verus network is completely fine and being finalized by Verus VIP against the Ethereum network. While it is possible for the Komodo notaries to fix their situation by upgrading, the network is fine whether they do or not.
Excited to announce the launch of https://verusmarkets.com! Stay updated with the latest prices & news on the #Verus $VRSC #Blockchain.
Verus #DeFi offers unique capabilities with its innovative multichain Currencies and Currency Baskets. Truly Decentralized conversions for all assets (including RWA & DePIN) for everyone. Anyone can launch a currency, basket of currencies or Public Blockchain as a Service (PBaaS) on Verus using simple commands.
A Developers playground awaits. Crypto enthusiasts can provide liquidity, create and/or hold a diverse portfolio of their favorite assets or Arbitrage their way to success. Entrepreneurs can start a business and instantly access rent-free unlimited-scale public infrastructure ready for #web3 #Dapp's. Limited only by your imagination, everyone's welcome.
Verus Technology will be on full display at #Consenus2024 (booth 1245). Dev's and Community members will be there to showcase the power of the Verus protocol and answer all your questions.
Verus #DeFi offers unique capabilities with its innovative multichain Currencies and Currency Baskets. Truly Decentralized conversions for all assets (including RWA & DePIN) for everyone. Anyone can launch a currency, basket of currencies or Public Blockchain as a Service (PBaaS) on Verus using simple commands.
A Developers playground awaits. Crypto enthusiasts can provide liquidity, create and/or hold a diverse portfolio of their favorite assets or Arbitrage their way to success. Entrepreneurs can start a business and instantly access rent-free unlimited-scale public infrastructure ready for #web3 #Dapp's. Limited only by your imagination, everyone's welcome.
Verus Technology will be on full display at #Consenus2024 (booth 1245). Dev's and Community members will be there to showcase the power of the Verus protocol and answer all your questions.
Announcing Verus v1.2.3 -
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-testnet
MANDATORY UPDATE FOR MAINNET VERUS, vARRR, AND TESTNET - MASSIVE RAM USAGE (> 2GB) REDUCTION AND BASKET UNBLOCK IT IS IMPORTANT TO UPGRADE TO v1.2.3 BEFORE ACTIVATION IN ORDER TO CONTINUE SYNCHRONIZING TO THE CHAIN BY THE FOLLOWING BLOCKS: Verus mainnet: 3093850 (just over 2 days from now) vARRR mainnet: 107590 (just over 4 days from now) Testnet: immediately THIS IS AN URGENT AND MANDATORY UPDATE, REQUIRED TO RESTART PROCESSING OF THE “SWITCH” BASKET CURRENCY IF YOU DO NOT UPGRADE IN TIME AND HAVE NOT CHANGED THE DEFAULT ORACLE, WE WILL ACTIVATE A NOTIFICATION THAT WILL PAUSE YOUR NODE AND ALLOW YOU TO UPGRADE AND RESUME WITHOUT NEEDING A BOOTSTRAP WHEN YOU ARE ABLE
What’s new?
1) v1.2.3 contains a massive optimization to the use of RAM for storing chain data and implements a real time compression technique called RLE, or run length encoding, on objects in memory to reduce RAM usage by over 2GB on Verus mainnet. This change will give more headroom on node machines that may have been struggling with growing RAM requirements and enable people to run more blockchains on a single node machine. (a lot slower speed of loading)
2) v1.2.3 addresses stalled processing of the Switch basket currency that has occurred on mainnet. This release addresses the issue at activation and ensures that the same thing won’t happen in the future. There are no other protocol changes for v1.2.3. Please update as soon as you are able to do so.
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-testnet
MANDATORY UPDATE FOR MAINNET VERUS, vARRR, AND TESTNET - MASSIVE RAM USAGE (> 2GB) REDUCTION AND BASKET UNBLOCK IT IS IMPORTANT TO UPGRADE TO v1.2.3 BEFORE ACTIVATION IN ORDER TO CONTINUE SYNCHRONIZING TO THE CHAIN BY THE FOLLOWING BLOCKS: Verus mainnet: 3093850 (just over 2 days from now) vARRR mainnet: 107590 (just over 4 days from now) Testnet: immediately THIS IS AN URGENT AND MANDATORY UPDATE, REQUIRED TO RESTART PROCESSING OF THE “SWITCH” BASKET CURRENCY IF YOU DO NOT UPGRADE IN TIME AND HAVE NOT CHANGED THE DEFAULT ORACLE, WE WILL ACTIVATE A NOTIFICATION THAT WILL PAUSE YOUR NODE AND ALLOW YOU TO UPGRADE AND RESUME WITHOUT NEEDING A BOOTSTRAP WHEN YOU ARE ABLE
What’s new?
1) v1.2.3 contains a massive optimization to the use of RAM for storing chain data and implements a real time compression technique called RLE, or run length encoding, on objects in memory to reduce RAM usage by over 2GB on Verus mainnet. This change will give more headroom on node machines that may have been struggling with growing RAM requirements and enable people to run more blockchains on a single node machine. (a lot slower speed of loading)
2) v1.2.3 addresses stalled processing of the Switch basket currency that has occurred on mainnet. This release addresses the issue at activation and ensures that the same thing won’t happen in the future. There are no other protocol changes for v1.2.3. Please update as soon as you are able to do so.
GitHub
Release v1.2.3 · VerusCoin/VerusCoin
Announcing Verus v1.2.3 - MANDATORY UPDATE FOR MAINNET VERUS, vARRR, AND TESTNET - MASSIVE RAM USAGE (> 2GB) REDUCTION AND BASKET UNBLOCK
IT IS IMPORTANT TO UPGRADE TO v1.2.3 BEFORE ACTIVATION ...
IT IS IMPORTANT TO UPGRADE TO v1.2.3 BEFORE ACTIVATION ...
Veruscoin Announcements pinned «Announcing Verus v1.2.3 - CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3 GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3 GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3…»
Announcing Verus v1.2.3-2 - CRITICAL UPGRADE FOR NETWORK STABILITY HIGHLY RECOMMENDED ALL USERS, ESPECIALLY BLOCK PRODUCERS AND WITNESSES.
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3-2
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-2
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-2-testnet
Yesterday, we identified and investigated a minor fork. This process exposed a rare race condition which had been latent but was triggered by an unusual combination of events in the network. v1.2.3-2 addresses this and all similar potential issues. While it's unlikely to reoccur, we consider it a critical upgrade that eliminates the possibility entirely.
GUI only: The VRSC and VRSCTEST chains will only launch with fastload enabled. A Verus Desktop version that provides users the option to enable or disable fastload will be released soon. There are no protocol or other changes for v1.2.3-2
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3-2
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-2
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-2-testnet
Yesterday, we identified and investigated a minor fork. This process exposed a rare race condition which had been latent but was triggered by an unusual combination of events in the network. v1.2.3-2 addresses this and all similar potential issues. While it's unlikely to reoccur, we consider it a critical upgrade that eliminates the possibility entirely.
GUI only: The VRSC and VRSCTEST chains will only launch with fastload enabled. A Verus Desktop version that provides users the option to enable or disable fastload will be released soon. There are no protocol or other changes for v1.2.3-2
GitHub
Release v1.2.3-2 · VerusCoin/VerusCoin
Announcing Verus v1.2.3-2 - CRITICAL UPGRADE FOR NETWORK STABILITY HIGHLY RECOMMENDED ALL USERS, ESPECIALLY BLOCK PRODUCERS AND WITNESSES.
Yesterday, we identified and investigated a minor fork. Th...
Yesterday, we identified and investigated a minor fork. Th...
Veruscoin Announcements pinned «Announcing Verus v1.2.3-2 - CRITICAL UPGRADE FOR NETWORK STABILITY HIGHLY RECOMMENDED ALL USERS, ESPECIALLY BLOCK PRODUCERS AND WITNESSES. CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3-2 GUI RELEASE: https://github.com/VerusCoin/Verus…»
Announcing Verus v1.2.3-3 - HIGHLY RECOMMENDED UPDATE FOR MAINNET VERUS, vARRR, AND TESTNET - IMPROVED MERGE-MINING AND MERGE-STAKING PERFORMANCE AND NEW AGGREGATED VOLUME AND BASKET DATA IN RPC & CLI WE HIGHLY RECOMMEND THIS UPDATE FOR ALL BLOCK PRODUCERS, POOLS, EXCHANGES, INFRASTRUCTURE SERVERS, AND WITNESSES
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3-3
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-3
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-3-testnet
What’s new in v1.2.3-3?
1) Enables the GUI to select significantly more memory efficient operation or fast loading and remembers the user setting. Defaults to fast loading.
2) Improves the connection between nodes for merge mining or staking, which may result in more efficient merge mining and staking.
3) Supports a new parameter and function on the getcurrencystate command or RPC call. This parameter is the currency to use for calculating volume, and if present, the API can be used to calculate and return volumes between any currencies in a basket calculated in any currency that may also be in the basket, or the basket itself. This should provide all the data aggregation needed, using import information, for people to make these available as basket data feeds to coinpaprika.com or other aggregators and for developers to have an easier time making Verus DeFi APIs, dashboards, or tools.
We recommend this update for everyone and recommend updating as soon as you are able to do so.
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3-3
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-3
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-3-testnet
What’s new in v1.2.3-3?
1) Enables the GUI to select significantly more memory efficient operation or fast loading and remembers the user setting. Defaults to fast loading.
2) Improves the connection between nodes for merge mining or staking, which may result in more efficient merge mining and staking.
3) Supports a new parameter and function on the getcurrencystate command or RPC call. This parameter is the currency to use for calculating volume, and if present, the API can be used to calculate and return volumes between any currencies in a basket calculated in any currency that may also be in the basket, or the basket itself. This should provide all the data aggregation needed, using import information, for people to make these available as basket data feeds to coinpaprika.com or other aggregators and for developers to have an easier time making Verus DeFi APIs, dashboards, or tools.
We recommend this update for everyone and recommend updating as soon as you are able to do so.
GitHub
Release v1.2.3-3 · VerusCoin/VerusCoin
Announcing Verus v1.2.3-3 - HIGHLY RECOMMENDED UPDATE FOR MAINNET VERUS, vARRR, AND TESTNET - IMPROVED MERGE-MINING AND MERGE-STAKING PERFORMANCE AND NEW AGGREGATED VOLUME AND BASKET DATA IN RPC &...
Veruscoin Announcements pinned «Announcing Verus v1.2.3-3 - HIGHLY RECOMMENDED UPDATE FOR MAINNET VERUS, vARRR, AND TESTNET - IMPROVED MERGE-MINING AND MERGE-STAKING PERFORMANCE AND NEW AGGREGATED VOLUME AND BASKET DATA IN RPC & CLI WE HIGHLY RECOMMEND THIS UPDATE FOR ALL BLOCK PRODUCERS…»
This is a PSA. If you use the Testflight "Verus Wallet" on iPhone, it will be removed from Testflight in 3 days from now. If you have any keys in the Testflight Wallet, please take a few moments to save them and/or get them moved over to the main iOS App Store "Verus Mobile" wallet.
From miketout in discord
Today, I noticed that there was a challenge of a notarization between vARRR and Verus. This was caused by a small reorg on the vARRR chain. As per the protocol, vARRR now needs to prove to the Verus chain that new notarizations are on the correct and most powerful chain for Verus to accept the cross chain notarization. While complete protocol function in challenge cases was tested for years on testnet, we have discovered a check that will treat the protocol differently, depending on the protocol version expected, based on block height. Unfortunately, the block height checked as a threshold is in error, and a vARRR block height is being checked against a Verus block height, which did work in all cases on testnet, but on mainnet is resulting in the proof being rejected. Until this is fixed, which is simple and in progress, but will require a protocol change on Verus, cross chain sends from vARRR to Verus are stalled. The other direction will soon pause as well until this is resolved. We hope to have a version out ASAP with a resolution and a target date for the update to take place. Our current target is a one week upgrade activation with the potential to activate it earlier if the community decides.
Today, I noticed that there was a challenge of a notarization between vARRR and Verus. This was caused by a small reorg on the vARRR chain. As per the protocol, vARRR now needs to prove to the Verus chain that new notarizations are on the correct and most powerful chain for Verus to accept the cross chain notarization. While complete protocol function in challenge cases was tested for years on testnet, we have discovered a check that will treat the protocol differently, depending on the protocol version expected, based on block height. Unfortunately, the block height checked as a threshold is in error, and a vARRR block height is being checked against a Verus block height, which did work in all cases on testnet, but on mainnet is resulting in the proof being rejected. Until this is fixed, which is simple and in progress, but will require a protocol change on Verus, cross chain sends from vARRR to Verus are stalled. The other direction will soon pause as well until this is resolved. We hope to have a version out ASAP with a resolution and a target date for the update to take place. Our current target is a one week upgrade activation with the potential to activate it earlier if the community decides.
From miketout in discord
Today, I noticed that there was a challenge of a notarization between vARRR and Verus. This was caused by a small reorg on the vARRR chain. As per the protocol, vARRR now needs to prove to the Verus chain that new notarizations are on the correct and most powerful chain for Verus to accept the cross chain notarization. While complete protocol function in challenge cases was tested for years on testnet, we have discovered a check that will treat the protocol differently, depending on the protocol version expected, based on block height. Unfortunately, the block height checked as a threshold is in error, and a vARRR block height is being checked against a Verus block height, which did work in all cases on testnet, but on mainnet is resulting in the proof being rejected. Until this is fixed, which is simple and in progress, but will require a protocol change on Verus, cross chain sends from vARRR to Verus are stalled. The other direction will soon pause as well until this is resolved. We hope to have a version out ASAP with a resolution and a target date for the update to take place. Our current target is a one week upgrade activation with the potential to activate it earlier if the community decides.
Today, I noticed that there was a challenge of a notarization between vARRR and Verus. This was caused by a small reorg on the vARRR chain. As per the protocol, vARRR now needs to prove to the Verus chain that new notarizations are on the correct and most powerful chain for Verus to accept the cross chain notarization. While complete protocol function in challenge cases was tested for years on testnet, we have discovered a check that will treat the protocol differently, depending on the protocol version expected, based on block height. Unfortunately, the block height checked as a threshold is in error, and a vARRR block height is being checked against a Verus block height, which did work in all cases on testnet, but on mainnet is resulting in the proof being rejected. Until this is fixed, which is simple and in progress, but will require a protocol change on Verus, cross chain sends from vARRR to Verus are stalled. The other direction will soon pause as well until this is resolved. We hope to have a version out ASAP with a resolution and a target date for the update to take place. Our current target is a one week upgrade activation with the potential to activate it earlier if the community decides.
Announcing Verus v1.2.3-5 - MANDATORY UPDATE FOR MAINNET, HIGHLY RECOMMENDED FOR TESTNET TO ADDRESS A CROSS-CHAIN TRAFFIC BLOCKAGE BETWEEN Verus AND vARRR BLOCKCHAINS, AND TO PREVENT ANY SIMILAR BLOCKAGE IN THE FUTURE ON ANY CHAIN, THIS VERSION IS MANDATORY TO STAY CONNECTED TO MAINNET CHAINS AND RECOMMENDED FOR TESTNET.
PLEASE UPGRADE BEFORE: VERUS MAINNET BLOCK 3143920 - EXPECTED AT ~17:00 UTC ON MONDAY, JULY 22ND
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3-5
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-5
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-5-testnet
It is possible, if the community decides, to change the activation time to either earlier or later via oracle notification. If the community does decide to change the activation, for example after Tuesday’s meeting, it will be announced here with the most possible notice. We hope and believe this target activation should be acceptable notice and also timely enough for all users.
As long as people do not change the default notification oracle for their Verus nodes, nodes older than v1.2.3-5 running on the Verus blockchain will pause and wait for upgrade just before the activation block. If you do not have time to update in the next week or before activation, and this happens to you, you should be able to simply close, upgrade, and continue when you are able.
Verus v1.2.3-5 contains a fix in the verification code for advanced cross-chain proofs that was falsely rejecting valid cross-chain proofs between Verus and PBaaS chains, only in the case of mainnet.
There are no other protocol or functional changes in v1.2.3-5.
PLEASE UPGRADE BEFORE: VERUS MAINNET BLOCK 3143920 - EXPECTED AT ~17:00 UTC ON MONDAY, JULY 22ND
CLI RELEASE: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.2.3-5
GUI RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-5
GUI TESTNET RELEASE: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.2.3-5-testnet
It is possible, if the community decides, to change the activation time to either earlier or later via oracle notification. If the community does decide to change the activation, for example after Tuesday’s meeting, it will be announced here with the most possible notice. We hope and believe this target activation should be acceptable notice and also timely enough for all users.
As long as people do not change the default notification oracle for their Verus nodes, nodes older than v1.2.3-5 running on the Verus blockchain will pause and wait for upgrade just before the activation block. If you do not have time to update in the next week or before activation, and this happens to you, you should be able to simply close, upgrade, and continue when you are able.
Verus v1.2.3-5 contains a fix in the verification code for advanced cross-chain proofs that was falsely rejecting valid cross-chain proofs between Verus and PBaaS chains, only in the case of mainnet.
There are no other protocol or functional changes in v1.2.3-5.
GitHub
Release v1.2.3-5 · VerusCoin/VerusCoin
MANDATORY UPDATE FOR MAINNET, HIGHLY RECOMMENDED FOR TESTNET
TO ADDRESS A CROSS-CHAIN TRAFFIC BLOCKAGE BETWEEN Verus AND vARRR BLOCKCHAINS, AND TO PREVENT ANY SIMILAR BLOCKAGE IN THE FUTURE ON ANY ...
TO ADDRESS A CROSS-CHAIN TRAFFIC BLOCKAGE BETWEEN Verus AND vARRR BLOCKCHAINS, AND TO PREVENT ANY SIMILAR BLOCKAGE IN THE FUTURE ON ANY ...
Veruscoin Announcements pinned «Announcing Verus v1.2.3-5 - MANDATORY UPDATE FOR MAINNET, HIGHLY RECOMMENDED FOR TESTNET TO ADDRESS A CROSS-CHAIN TRAFFIC BLOCKAGE BETWEEN Verus AND vARRR BLOCKCHAINS, AND TO PREVENT ANY SIMILAR BLOCKAGE IN THE FUTURE ON ANY CHAIN, THIS VERSION IS MANDATORY…»
For people who may not know how to get basic information on the vDEX launch, here are some facts about it, in addition to what I've said above, that you can learn from the on-chain definition:
1) vDEX will launch as a Proof of Power (50% PoW/50%PoS) PBaaS blockchain connected to the rest of the Verus network and indirectly to Ethereum, and this launch increases the total bandwidth, processing, and storage capability of the PBaaS Internet of Value.
2) vDEX has a 1 minute block time and is merge mineable with Verus, vARRR, and future PBaaS blockchains
3) Staking is permissionless and you do not need a
4) vDEX bridge converter is in pre-launch mode and will operate on the vDEX chain when it goes live. Again, it will be 100% backed with 20% by each of VRSC, vDEX, vETH, DAI.vETH, and tBTC.vETH. The actual amounts of each will be determined by the pre-launch phase and on-chain pre-conversions/arbitrage.
5) Over the life of the blockchain, the total supply of vDEX, which is almost all distributed to vDEX holders, will max out at 1 million vDEX. Bridge.vDEX will start at 100K supply, regardless of how much people participate in pre-launch. 5K of that is being donated to "Verus Coin Foundation@", to be used for the benefit of the Verus network, and 10K will go to Supernet. There will also be a 5% pre-launch discount for all pre-conversion transactions relative to the final on-chain conversion rate at launch. This is built into the protocol and was specified in the currency definition so that the final reserve backing will be 100% between all currencies.
6) The vDEX blockchain will support the same storage, currency, data, and ID APIs as Verus, and fees on the vDEX chain for IDs, currencies, storage, and other things have been set to be lower, as there is less vDEX available for use. For example, it has a *.vDEX ID price of 1 vDEX, a currency launch is 10 vDEX, etc.
1) vDEX will launch as a Proof of Power (50% PoW/50%PoS) PBaaS blockchain connected to the rest of the Verus network and indirectly to Ethereum, and this launch increases the total bandwidth, processing, and storage capability of the PBaaS Internet of Value.
2) vDEX has a 1 minute block time and is merge mineable with Verus, vARRR, and future PBaaS blockchains
3) Staking is permissionless and you do not need a
*.vDEX ID to stake, only some vDEX in a staking node's wallet4) vDEX bridge converter is in pre-launch mode and will operate on the vDEX chain when it goes live. Again, it will be 100% backed with 20% by each of VRSC, vDEX, vETH, DAI.vETH, and tBTC.vETH. The actual amounts of each will be determined by the pre-launch phase and on-chain pre-conversions/arbitrage.
5) Over the life of the blockchain, the total supply of vDEX, which is almost all distributed to vDEX holders, will max out at 1 million vDEX. Bridge.vDEX will start at 100K supply, regardless of how much people participate in pre-launch. 5K of that is being donated to "Verus Coin Foundation@", to be used for the benefit of the Verus network, and 10K will go to Supernet. There will also be a 5% pre-launch discount for all pre-conversion transactions relative to the final on-chain conversion rate at launch. This is built into the protocol and was specified in the currency definition so that the final reserve backing will be 100% between all currencies.
6) The vDEX blockchain will support the same storage, currency, data, and ID APIs as Verus, and fees on the vDEX chain for IDs, currencies, storage, and other things have been set to be lower, as there is less vDEX available for use. For example, it has a *.vDEX ID price of 1 vDEX, a currency launch is 10 vDEX, etc.