VerusMiner update has been released. 📣📣📣
Version : 3.3.0
✅ Added speed test feature
◽️mining pool connection speed can now be tested
◽️this is an experimental feature so some issues can be expected
✅ Mining improvements
◽️miner binary update with hashing optimization
✅ Minor UI improvements
◽️app and miner version is added at the main mining screen
✅ Bug fix
◽️pool drop-down default value is set correctly when scanning a setting
Topic: [ANN] Verus (VRSC) - zk-SNARK privacy, CPU-mining, 50/50 POW/POS, fair launch - page 5. (Read 49832 times)
June 11, 2023, 12:18:20 AM
June 09, 2023, 08:29:17 PM
Announcing v1.0.8 - MANDATORY UPGRADE FOR MAINNET AND TESTNET MAINNET UPGRADE
MAINNET DEFAULT RELEASES
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.8
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.8
TESTNET SPECIFIC
GUI: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.8-testnet
REQUIRED BY BLOCK 2578653, EXPECTED THIS COMING TUESDAY, 17:00 UTC TESTNET UPGRADE REQUIRED BY TESTNET BLOCK 69013, EXPECTED THIS SATURDAY, 17:00 UTC
Once we pass the blocks above, we will remove the DeFi oracle notification, and all PBaaS and DeFi functions, including currency and chain launches, will reactivate on mainnet with full function and some new capabilities described below. To ensure a smooth transition on testnet and a resulting testnet with only refunded or launched currencies, none in between, and no extra work to make that true, we have also pushed a testnet DeFi oracle notification that will be removed Saturday morning.
What’s New Fixes: Two related issues around the time of the whales launch made it clear that we were not handling the maximum limits of currency launches properly and were allowing people to exceed those limits in their pre-launch participation, even though these features had been working in basic testing that did not push edge conditions. While it’s related to the fact that there are pre-launch and post-launch phases of a currency launch that may even happen on different chains, the way these limits were handled in the pre-1.0.8 protocol made it very difficult/impossible to cleanly handle all edge cases we were throwing at it, especially once we added the complexity of co-launching a bridge currency and PBaaS chain, and the pre-launch and post-launch being resolved on different chains. To ensure we have all of that covered, @Asher and @englal really stepped up with heroic levels of contribution to testing, release prep, and confirming every possible edge case we could construct, enabling us to have confidence that the new way of handling everything is complete, robust, and has as close to 100% test coverage on all launch cases as is reasonably possible. Of course, we will be happy to have lots of testing after the activation on testnet and lots of use on mainnet.
New feature: Pre-1.0.8, in addition to an unlimited number of multi-currency liquidity basket configurations, you could also launch decentralized or centralized tokens, crowdfunding style, and even allow people to pre-convert to native PBaaS currencies. For non-liquidity tokens, converted funds for tokens are sent to the ID of the token or chain, meaning that these types of tokens are well suited for complex payment resolution or can be used for non-financial things like forms of voting or tracking as well.
Prior to v1.0.8, the only currency that could be used for pre-launch in tokens of this kind was either Verus or the native currency of the PBaaS chain launching such a currency. In 1.0.8, up to 9 additional currencies can be used along with the native currency, each having its own minimum and maximum participation levels, whether the launch is on-chain or launching a chain. That means that you could launch a token or blockchain with independent conversion rates and currency options set for conversion from Verus, Ethereum, DAI, a branded currency, project currency, or any other currency available on the launching chain. For example, if a project that has a token, like an ERC20 wanted to migrate their entire network to an independent, fully functional PBaaS blockchain, they could enable holders of that token to use the protocol to participate in a 1:1 or 10:1 pre-launch for the native currency of the new blockchain. While every launch does need to accept the native currency of the blockchain launching it, min and max limits are supported on all currencies in the launch, enabling an unlimited number of new launch possibilities. After going through testing scenario upon testing scenario and every permutation we could come up with to throw at it, I’m convinced that this new capability is a powerful tool to round out our already quite complete protocol for the Internet of Value.
We’re a community project building fully in the open, and while it would have been great to skip having these issues altogether, I am grateful and truly impressed with the pulling together over the past week as some of us have been putting all we’ve got into this release, and the protocol and project move forward better and stronger as a result. I feel very good about v1.0.8 and the network’s state in general, both testnet and mainnet. Thank you all for helping us get here, now let’s all upgrade, remove the DeFi oracle, and get some mainnet projects truly underway!
MAINNET DEFAULT RELEASES
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.8
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.8
TESTNET SPECIFIC
GUI: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.8-testnet
REQUIRED BY BLOCK 2578653, EXPECTED THIS COMING TUESDAY, 17:00 UTC TESTNET UPGRADE REQUIRED BY TESTNET BLOCK 69013, EXPECTED THIS SATURDAY, 17:00 UTC
Once we pass the blocks above, we will remove the DeFi oracle notification, and all PBaaS and DeFi functions, including currency and chain launches, will reactivate on mainnet with full function and some new capabilities described below. To ensure a smooth transition on testnet and a resulting testnet with only refunded or launched currencies, none in between, and no extra work to make that true, we have also pushed a testnet DeFi oracle notification that will be removed Saturday morning.
What’s New Fixes: Two related issues around the time of the whales launch made it clear that we were not handling the maximum limits of currency launches properly and were allowing people to exceed those limits in their pre-launch participation, even though these features had been working in basic testing that did not push edge conditions. While it’s related to the fact that there are pre-launch and post-launch phases of a currency launch that may even happen on different chains, the way these limits were handled in the pre-1.0.8 protocol made it very difficult/impossible to cleanly handle all edge cases we were throwing at it, especially once we added the complexity of co-launching a bridge currency and PBaaS chain, and the pre-launch and post-launch being resolved on different chains. To ensure we have all of that covered, @Asher and @englal really stepped up with heroic levels of contribution to testing, release prep, and confirming every possible edge case we could construct, enabling us to have confidence that the new way of handling everything is complete, robust, and has as close to 100% test coverage on all launch cases as is reasonably possible. Of course, we will be happy to have lots of testing after the activation on testnet and lots of use on mainnet.
New feature: Pre-1.0.8, in addition to an unlimited number of multi-currency liquidity basket configurations, you could also launch decentralized or centralized tokens, crowdfunding style, and even allow people to pre-convert to native PBaaS currencies. For non-liquidity tokens, converted funds for tokens are sent to the ID of the token or chain, meaning that these types of tokens are well suited for complex payment resolution or can be used for non-financial things like forms of voting or tracking as well.
Prior to v1.0.8, the only currency that could be used for pre-launch in tokens of this kind was either Verus or the native currency of the PBaaS chain launching such a currency. In 1.0.8, up to 9 additional currencies can be used along with the native currency, each having its own minimum and maximum participation levels, whether the launch is on-chain or launching a chain. That means that you could launch a token or blockchain with independent conversion rates and currency options set for conversion from Verus, Ethereum, DAI, a branded currency, project currency, or any other currency available on the launching chain. For example, if a project that has a token, like an ERC20 wanted to migrate their entire network to an independent, fully functional PBaaS blockchain, they could enable holders of that token to use the protocol to participate in a 1:1 or 10:1 pre-launch for the native currency of the new blockchain. While every launch does need to accept the native currency of the blockchain launching it, min and max limits are supported on all currencies in the launch, enabling an unlimited number of new launch possibilities. After going through testing scenario upon testing scenario and every permutation we could come up with to throw at it, I’m convinced that this new capability is a powerful tool to round out our already quite complete protocol for the Internet of Value.
We’re a community project building fully in the open, and while it would have been great to skip having these issues altogether, I am grateful and truly impressed with the pulling together over the past week as some of us have been putting all we’ve got into this release, and the protocol and project move forward better and stronger as a result. I feel very good about v1.0.8 and the network’s state in general, both testnet and mainnet. Thank you all for helping us get here, now let’s all upgrade, remove the DeFi oracle, and get some mainnet projects truly underway!
May 31, 2023, 01:30:58 AM
Announcing v1.0.7 - UPGRADE HIGHLY RECOMMENDED FOR MAINNET, MANDATORY FOR CONTINUED TESTNET USE ALL PBAAS AND DEFI FUNCTIONS HAVE NOW RESUMED ON MAINNET. PLEASE MAKE SURE YOU ARE RUNNING v1.0.6 OR LATER AT THIS TIME TESTNET USERS SHOULD UPGRADE ASAP, AS USUAL. THERE WILL BE A FORKING CHANGE ON TESTNET THAT WILL ACTIVATE TO RE-ENABLE ZERO EMISSION PBAAS CHAIN CHALLENGES TOMORROW, AFTER 19:00 UTC
MAINNET DEFAULT RELEASES
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.7
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.7
TESTNET SPECIFIC
GUI: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.7-testnet
This release marks the completion and full resolution of the investigations that led to the PBaaS and DeFi pauses. As mentioned, all LP fees from exiting a DeFi basket’s primary currency will now be properly burned into those currencies before conversion operations take place. Shortly before this announcement, all oracle notarizations that were suppressing DeFi, currency sub-ID registrations, and PBaaS chain launches were lifted from the network. That means all PBaaS functions are now live and fully operational! Please note: Though the last mandatory upgrade was v1.0.6, and this is not technically a mandatory upgrade, it does address the known and understood issue only affecting zero reward PBaaS chains that can create issues with cross-chain challenges.
Until everyone is known to be on v1.0.7 or later, and we announce that such PBaaS configurations are well supported on the network, we recommend that no one launch a PBaaS chain that has zero block reward emissions. If you choose to do so anyhow, your chain should properly launch, but for about the next month, you may have issues with cross-chain function, unless you understand and plan appropriately. If launching a chain with zero emissions is important to you, and you seriously can’t wait, please discuss with someone in development or support to understand your options. We don’t believe that this is a critical early use case, so we actually don’t expect it to be an issue for anyone. Our next step is the testnet rollout of the Ethereum bridge, and after a few days of that proving out in final testing and review, we will deploy it on mainnet as soon as we believe it is ready for permanent use. Once the Ethereum bridge is live on mainnet, if we do ever need a contract upgrade, we will announce and coordinate with network validators, as each Ethereum contract upgrade will be independently subject to Verus miner and staker approval. Thanks everyone for upgrading as soon as you are able!
MAINNET DEFAULT RELEASES
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.7
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.7
TESTNET SPECIFIC
GUI: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.7-testnet
This release marks the completion and full resolution of the investigations that led to the PBaaS and DeFi pauses. As mentioned, all LP fees from exiting a DeFi basket’s primary currency will now be properly burned into those currencies before conversion operations take place. Shortly before this announcement, all oracle notarizations that were suppressing DeFi, currency sub-ID registrations, and PBaaS chain launches were lifted from the network. That means all PBaaS functions are now live and fully operational! Please note: Though the last mandatory upgrade was v1.0.6, and this is not technically a mandatory upgrade, it does address the known and understood issue only affecting zero reward PBaaS chains that can create issues with cross-chain challenges.
Until everyone is known to be on v1.0.7 or later, and we announce that such PBaaS configurations are well supported on the network, we recommend that no one launch a PBaaS chain that has zero block reward emissions. If you choose to do so anyhow, your chain should properly launch, but for about the next month, you may have issues with cross-chain function, unless you understand and plan appropriately. If launching a chain with zero emissions is important to you, and you seriously can’t wait, please discuss with someone in development or support to understand your options. We don’t believe that this is a critical early use case, so we actually don’t expect it to be an issue for anyone. Our next step is the testnet rollout of the Ethereum bridge, and after a few days of that proving out in final testing and review, we will deploy it on mainnet as soon as we believe it is ready for permanent use. Once the Ethereum bridge is live on mainnet, if we do ever need a contract upgrade, we will announce and coordinate with network validators, as each Ethereum contract upgrade will be independently subject to Verus miner and staker approval. Thanks everyone for upgrading as soon as you are able!
May 28, 2023, 11:30:01 PM
Announcing v1.0.6 - MANDATORY MAINNET UPGRADE WITH COMMUNITY AGREED DEADLINE ON TUESDAY, MAY 30th, 19:00 UTC
MAINNET DEFAULT RELEASES
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.6
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.6
TESTNET SPECIFIC GUI: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.6-testnet
As everyone using the network can see, someone launched a currency on the chain called RaceCondition, which is a 5% algorithmically controlled fractional reserve of Verus. While these currencies are tools, and there may be good reasons for 5% components or even 5% currencies in some applications, this was a VERY low reserve (launched with 10 VRSC in reserves), high supply currency (100 million supply), and as volatile as the protocol allows at 5%, meaning as people convert to it, it will go up quickly and as they convert away from it, it will also go down very quickly. The extreme nature of the currency made a behavior look slightly different than what I would have expected, which is that when someone converted into the currency, which was obviously extremely centralized on one individual, that individual then converted all of the currency they held to VRSC, capturing the highest price they could get and leaving the currency with far fewer reserves as a result of the large majority of the supply converting away from a highly volatile, 5% currency. All of that was expected.
The thing that made me take notice is that after all had happened, there seemed to be more reserve than I’d expect in the currency still, and that turned out to be because only in the case of a conversion from fractional to a reserve, not in reserve to reserve conversion or any other case, the portion of the fractional currency that should have been burned into the basket was not being burned, and those fees were not being captured. Interestingly, it resulted in a buffer for the person who entered RaceCondition for 5 VRSC and subsequently had 4 of them taken on the exit from one person of 100,000,000 of the supply. It turns out that the lack of the fee burn was the totality of the issue we found, and though it may not seem that serious, all of these calculations are consensus. They are there to create incentive for positive network contribution, and we take any error that we find in them, fees or otherwise, quite seriously. The fix means that all fees, including the fractional fees on an exit from a liquidity basket are now burned before conversions take place, which in this case, where the final price was just 14 SATs due to the extreme difference between reserves and supply numbers, would enable the person who exited with 100MM RaceCondition to take 15 VRSC, as the correct fee allocation actually results in a 15 SAT price, which means the person who remains holding the RaceCondition bag would have only some 100s of thousands of SATs for the supply they hold. The lesson here is to pay attention to the total reserve ratio, what coins are in a basket, and see that there is enough liquidity of reserves for a basket to make sense. Of course baskets could be memes, but they have real function. Make sure you take a look into how a basket works and that you have a reason before putting your hard mined, staked, won, or purchased Verus in. We will need the network to mostly upgrade to version 1.0.6 before we can re-enable DeFi and cross-chain functions, enabling deployment of the ETH bridge launch, PBaaS launches, and on-chain conversions to continue. We see that someone is launching a currency called “whales”, which looks like a currency that will enable registering IDs with 3 levels of referrals in a currency that simply collects registration fees, which likely get more expensive over time. The startblock for whales is 2561900, which should happen somewhere around 6:00 UTC on Thursday. That means that if we can upgrade and activate by Tuesday before the meeting, that person would still have time for pre-launch participation by those who would like. Thanks everyone for upgrading as soon as you are able!
MAINNET DEFAULT RELEASES
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.6
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.6
TESTNET SPECIFIC GUI: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.6-testnet
As everyone using the network can see, someone launched a currency on the chain called RaceCondition, which is a 5% algorithmically controlled fractional reserve of Verus. While these currencies are tools, and there may be good reasons for 5% components or even 5% currencies in some applications, this was a VERY low reserve (launched with 10 VRSC in reserves), high supply currency (100 million supply), and as volatile as the protocol allows at 5%, meaning as people convert to it, it will go up quickly and as they convert away from it, it will also go down very quickly. The extreme nature of the currency made a behavior look slightly different than what I would have expected, which is that when someone converted into the currency, which was obviously extremely centralized on one individual, that individual then converted all of the currency they held to VRSC, capturing the highest price they could get and leaving the currency with far fewer reserves as a result of the large majority of the supply converting away from a highly volatile, 5% currency. All of that was expected.
The thing that made me take notice is that after all had happened, there seemed to be more reserve than I’d expect in the currency still, and that turned out to be because only in the case of a conversion from fractional to a reserve, not in reserve to reserve conversion or any other case, the portion of the fractional currency that should have been burned into the basket was not being burned, and those fees were not being captured. Interestingly, it resulted in a buffer for the person who entered RaceCondition for 5 VRSC and subsequently had 4 of them taken on the exit from one person of 100,000,000 of the supply. It turns out that the lack of the fee burn was the totality of the issue we found, and though it may not seem that serious, all of these calculations are consensus. They are there to create incentive for positive network contribution, and we take any error that we find in them, fees or otherwise, quite seriously. The fix means that all fees, including the fractional fees on an exit from a liquidity basket are now burned before conversions take place, which in this case, where the final price was just 14 SATs due to the extreme difference between reserves and supply numbers, would enable the person who exited with 100MM RaceCondition to take 15 VRSC, as the correct fee allocation actually results in a 15 SAT price, which means the person who remains holding the RaceCondition bag would have only some 100s of thousands of SATs for the supply they hold. The lesson here is to pay attention to the total reserve ratio, what coins are in a basket, and see that there is enough liquidity of reserves for a basket to make sense. Of course baskets could be memes, but they have real function. Make sure you take a look into how a basket works and that you have a reason before putting your hard mined, staked, won, or purchased Verus in. We will need the network to mostly upgrade to version 1.0.6 before we can re-enable DeFi and cross-chain functions, enabling deployment of the ETH bridge launch, PBaaS launches, and on-chain conversions to continue. We see that someone is launching a currency called “whales”, which looks like a currency that will enable registering IDs with 3 levels of referrals in a currency that simply collects registration fees, which likely get more expensive over time. The startblock for whales is 2561900, which should happen somewhere around 6:00 UTC on Thursday. That means that if we can upgrade and activate by Tuesday before the meeting, that person would still have time for pre-launch participation by those who would like. Thanks everyone for upgrading as soon as you are able!
May 24, 2023, 09:06:02 PM
Announcing v1.0.5 - MANDATORY MAINNET UPGRADE WITH DEADLINE TBD BY COMMUNITY (STRAWMAN SUGGESTION MONDAY, MAY 29th, 19:00 UTC)
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.5
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.5
While preparing the cross-chain VRSC currency launch and as part of continual review, we determined that one numeric function that is used in the cross-chain challenges and is calculated differently for mainnet, due to the original launch that included the deprecated time locked rewards, was incorrect. This had never been hit, as it would have been calculated incorrectly only if multiple chains experienced a challenge of two competing forks, but in that case, it would falsely reject any challenge proof. That would mean cross-chain challenges on mainnet, even though they were fine and fully tested on testnet, could fail and block a bridge until that calculation was made correct and the network upgraded. Because we have the notification oracle technology, we triggered a rip-cord notification selectively for cross-chain function only, which made all nodes listening to the oracle, likely near 100%, disallow cross-chain operations without affecting same chain operations. That means that all functions on the Verus network, except launching PBaaS chains or Ethereum bridges are fully functional and unhampered in any way at this time. If someone tries to launch a PBaaS chain while this oracle notification is active, all nodes following the oracle will reject such an action without incident until the notification is removed. This release, v1.0.5, properly calculates the aptly named “magic number” for each chain, in the correct way on the mainnet network, and as long as the notification is set, is fully compatible with current versions on the network.
Once everyone has had a chance to upgrade to v1.0.5, the network/community should agree to remove the notification from the oracle and allow PBaaS launches without false rejection of cross-chain challenges. Once we do that, and when someone launches a PBaaS chain that issues such a challenge, the network would become incompatible with Verus versions prior to 1.0.5. From our perspective, we are not aware of urgent efforts to launch a PBaaS chain in the next few days by anyone who cannot wait. All things considered, we believe that we can at least wait until the community discussion on Saturday, and that a strawman deadline would be Monday, May 29th, at 19:00 UTC for everyone to have upgraded. If you are urgently wanting to launch a PBaaS chain, have a plan, and are prepared to do so sooner, we invite you to join the community meeting on Saturday at 19:00 UTC and let everyone know. Having this notification remain in place until removed keeps the network running smoothly as it has been since activation, with all DeFi, multicurrency, and non-cross-chain functions enabled. Since the ETH bridge is undergoing final changes and review, is not quite ready to launch on testnet or mainnet, and will likely require at least a couple days on testnet to finish its review, we do not believe the current notification is hampering or slowing anything or anyone down at this time. MAINNET DEFAULT RELEASES (TESTNET GUI TO FOLLOW)
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.5
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.5
While preparing the cross-chain VRSC currency launch and as part of continual review, we determined that one numeric function that is used in the cross-chain challenges and is calculated differently for mainnet, due to the original launch that included the deprecated time locked rewards, was incorrect. This had never been hit, as it would have been calculated incorrectly only if multiple chains experienced a challenge of two competing forks, but in that case, it would falsely reject any challenge proof. That would mean cross-chain challenges on mainnet, even though they were fine and fully tested on testnet, could fail and block a bridge until that calculation was made correct and the network upgraded. Because we have the notification oracle technology, we triggered a rip-cord notification selectively for cross-chain function only, which made all nodes listening to the oracle, likely near 100%, disallow cross-chain operations without affecting same chain operations. That means that all functions on the Verus network, except launching PBaaS chains or Ethereum bridges are fully functional and unhampered in any way at this time. If someone tries to launch a PBaaS chain while this oracle notification is active, all nodes following the oracle will reject such an action without incident until the notification is removed. This release, v1.0.5, properly calculates the aptly named “magic number” for each chain, in the correct way on the mainnet network, and as long as the notification is set, is fully compatible with current versions on the network.
Once everyone has had a chance to upgrade to v1.0.5, the network/community should agree to remove the notification from the oracle and allow PBaaS launches without false rejection of cross-chain challenges. Once we do that, and when someone launches a PBaaS chain that issues such a challenge, the network would become incompatible with Verus versions prior to 1.0.5. From our perspective, we are not aware of urgent efforts to launch a PBaaS chain in the next few days by anyone who cannot wait. All things considered, we believe that we can at least wait until the community discussion on Saturday, and that a strawman deadline would be Monday, May 29th, at 19:00 UTC for everyone to have upgraded. If you are urgently wanting to launch a PBaaS chain, have a plan, and are prepared to do so sooner, we invite you to join the community meeting on Saturday at 19:00 UTC and let everyone know. Having this notification remain in place until removed keeps the network running smoothly as it has been since activation, with all DeFi, multicurrency, and non-cross-chain functions enabled. Since the ETH bridge is undergoing final changes and review, is not quite ready to launch on testnet or mainnet, and will likely require at least a couple days on testnet to finish its review, we do not believe the current notification is hampering or slowing anything or anyone down at this time. MAINNET DEFAULT RELEASES (TESTNET GUI TO FOLLOW)
May 23, 2023, 06:32:48 PM
And its live!!
Happy PBaaS!!!
Happy PBaaS!!!
May 23, 2023, 06:14:19 AM
Please update your miners before block 2549420
CCminer Windows build has been released on GitHub.
CPU: https://github.com/monkins1010/ccminer/releases/tag/v3.8.3a
GPU: https://github.com/monkins1010/ccminer/releases/tag/v3.8.3
Hellminer https://github.com/hellcatz/hminer/releases
CCminer Windows build has been released on GitHub.
CPU: https://github.com/monkins1010/ccminer/releases/tag/v3.8.3a
GPU: https://github.com/monkins1010/ccminer/releases/tag/v3.8.3
Hellminer https://github.com/hellcatz/hminer/releases
May 23, 2023, 12:10:47 AM
Announcing v1.0.4 - CRITICAL, NON-MANDATORY MAINNET UPGRADE
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.4
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.4
THIS UPDATE IS CRITICAL FOR MAINNET DEFI OR CROSSCHAIN WALLET FUNCTIONS, AS IT RECTIFIES POTENTIAL REFUND FAILURES IN EDGE CASES - IT IS NOT REQUIRED FOR MAINNET SYNCHRONIZATION OR MAINNET FUNCTION PAST PBAAS ACTIVATION, BUT IT IS HIGHLY RECOMMENDED. DO BE SURE TO UPGRADE TO v1.0.3 OR LATER BEFORE MAY 23, 2023, EXPECTED BLOCK #2549420 FOR CONTINUED TESTNET USE, UPGRADE ASAP Mainnet improvements:
* Properly inserts refund addresses in all cases when making DeFi or cross-chain transactions
* Merge mining improvements from Hellcatz for higher merge mining performance on all platforms and full pool merge mining support when used in combination with @hellcatz and @𝙊𝙞𝙣𝙠 's SNomp pool improvements
* CLI now defaults to mainnet for all PBaaS chains unless -testnet is specified
* 2 versions of GUI will be released for now, a mainnet and separate testnet version. Full PBaaS support in the wallet will only be for either mainnet or testnet, depending on the version used.
* Extends deprecation height from the previous 20 weeks to 52 weeks
Testnet fixes/improvements:
* Separate GUI release for testnet
* Refund address fix
This the is last expected and recommended release before the mainnet activation, Tuesday at block #2549420. Please make sure you update to v1.0.3 or greater (v1.0.4 recommended) before the activation block. MAINNET DEFAULT RELEASES (TESTNET TO FOLLOW)
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.4
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.4
THIS UPDATE IS CRITICAL FOR MAINNET DEFI OR CROSSCHAIN WALLET FUNCTIONS, AS IT RECTIFIES POTENTIAL REFUND FAILURES IN EDGE CASES - IT IS NOT REQUIRED FOR MAINNET SYNCHRONIZATION OR MAINNET FUNCTION PAST PBAAS ACTIVATION, BUT IT IS HIGHLY RECOMMENDED. DO BE SURE TO UPGRADE TO v1.0.3 OR LATER BEFORE MAY 23, 2023, EXPECTED BLOCK #2549420 FOR CONTINUED TESTNET USE, UPGRADE ASAP Mainnet improvements:
* Properly inserts refund addresses in all cases when making DeFi or cross-chain transactions
* Merge mining improvements from Hellcatz for higher merge mining performance on all platforms and full pool merge mining support when used in combination with @hellcatz and @𝙊𝙞𝙣𝙠 's SNomp pool improvements
* CLI now defaults to mainnet for all PBaaS chains unless -testnet is specified
* 2 versions of GUI will be released for now, a mainnet and separate testnet version. Full PBaaS support in the wallet will only be for either mainnet or testnet, depending on the version used.
* Extends deprecation height from the previous 20 weeks to 52 weeks
Testnet fixes/improvements:
* Separate GUI release for testnet
* Refund address fix
This the is last expected and recommended release before the mainnet activation, Tuesday at block #2549420. Please make sure you update to v1.0.3 or greater (v1.0.4 recommended) before the activation block. MAINNET DEFAULT RELEASES (TESTNET TO FOLLOW)
May 20, 2023, 09:52:17 PM
Announcing v1.0.3 - MANDATORY MAINNET UPGRADE - HOPEFULLY THE LAST IN A WHILE - ACTIVATION DATE HAS BEEN PUSHED BY 2 DAYS
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.3
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.3
FOR CONTINUED MAINNET USE, UPGRADE TO v1.0.3 OR LATER BEFORE MAY 23, 2023, EXPECTED BLOCK #2549420
FOR CONTINUED TESTNET USE, UPGRADE ASAP
Mainnet: fixes:
Fixes an issue discovered that could have resulted in behavior different than what has been tested in an edge case when mainnet activates
Testnet fixes/improvements:
Forgives issues pre-1.0.2 on testnet that were blocking challenge resolution by lacking complete cryptographic proof for cross-chain notarization confirmation
What’s New
v1.0.3 has extended the API fundrawtransaction to allow Verus Mobile and other applications to easily construct transactions for DeFi conversions and cross-chain operations as well.
We expect at least one more non-mandatory release before the mainnet activation, Tuesday at block #2549420, which will add some pool merge mining improvements. Please make sure you update to v1.0.3 or greater before the activation block.
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.3
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.3
FOR CONTINUED MAINNET USE, UPGRADE TO v1.0.3 OR LATER BEFORE MAY 23, 2023, EXPECTED BLOCK #2549420
FOR CONTINUED TESTNET USE, UPGRADE ASAP
Mainnet: fixes:
Fixes an issue discovered that could have resulted in behavior different than what has been tested in an edge case when mainnet activates
Testnet fixes/improvements:
Forgives issues pre-1.0.2 on testnet that were blocking challenge resolution by lacking complete cryptographic proof for cross-chain notarization confirmation
What’s New
v1.0.3 has extended the API fundrawtransaction to allow Verus Mobile and other applications to easily construct transactions for DeFi conversions and cross-chain operations as well.
We expect at least one more non-mandatory release before the mainnet activation, Tuesday at block #2549420, which will add some pool merge mining improvements. Please make sure you update to v1.0.3 or greater before the activation block.
May 16, 2023, 06:34:44 AM
Announcing v1.0.2 - MANDATORY MAINNET UPGRADE
UPGRADE TO v1.0.2 OR LATER IS MANDATORY FOR CONTINUED MAINNET AND TESTNET USE AFTER MAY 21, 2023, EXPECTED BLOCK #2546600
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.2
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.2
Mainnet: fixes:
* Fixes a regression that prevented staking on locked IDs as well as modifying locked IDs
Testnet fixes/improvements:
* Fixes issues discovered when challenges occurred on the Gravity chain that blocked resolution of cross-chain challenges.
* Addresses all known issues discovered in testing
What’s New
v1.0.2 has no feature changes, some minor API fixes, proof improvements, and we believe the third time's a charm . The testnet will transition to the v1.0.2 protocol with no reset required, Wednesday, May 17, 2023 0:00:00, UTC.
UPGRADE TO v1.0.2 OR LATER IS MANDATORY FOR CONTINUED MAINNET AND TESTNET USE AFTER MAY 21, 2023, EXPECTED BLOCK #2546600
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.2
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.2
Mainnet: fixes:
* Fixes a regression that prevented staking on locked IDs as well as modifying locked IDs
Testnet fixes/improvements:
* Fixes issues discovered when challenges occurred on the Gravity chain that blocked resolution of cross-chain challenges.
* Addresses all known issues discovered in testing
What’s New
v1.0.2 has no feature changes, some minor API fixes, proof improvements, and we believe the third time's a charm . The testnet will transition to the v1.0.2 protocol with no reset required, Wednesday, May 17, 2023 0:00:00, UTC.
May 07, 2023, 08:04:35 PM
Announcing v1.0.1 - MANDATORY Mainnet Upgrade, UPGRADE TO v1.0.1 OR LATER IS MANDATORY FOR CONTINUED MAINNET AND TESTNET USE AFTER MAY 21, 2023, EXPECTED BLOCK #2546600
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.1
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.1
Issues addressed Mainnet: v1.0.1 fixes an issue where original stakeguard outputs from 2 years ago or before may not show up in a wallet after rescan. Now they will again.
Testnet: In addition to fixing an issue discovered by @cautionfun on the current public testnet, this version also addresses an issue discovered during additional coverage testing on the oracle based, reversible rip-cord implementations to ensure the ability for the network to respond to any unexpected events quickly, safely, and without compromise to decentralization.
What’s New In addition to the full PBaaS protocol and all capabilities previously described, version 1.0.1 will also include some new capabilities that were previously not in the PBaaS protocol. The capabilities basically extend the idea of a centralized currency to include the ability to launch temporarily centralized currencies, including those that can sell identities. While a currency is centralized in this mode, fees and proceeds from the issuance of IDs go directly to the currency ID and are not burned into the currency itself. This is achieved by setting the “endblock” on a centralized currency launch of either a token or liquidity basket, enabling:
1) In v1.0.1, setting the endblock of a centralized currency causes all centralized capabilities of the controlling ID to end when the endblock is reached, converting it in whatever state it currently is into a decentralized currency with no special control over it by any identity on the network after that occurs.
2) Registering identities on a currency. When an identity is registered on a centralized currency, the fee for the registration is not burned into the currency, but sent directly to the identity of the currency. This is true for token or liquidity basket currencies. For decentralized currencies, fees are burned, which on a liquidity basket, puts them into the liquidity pool for all LPs to share in earnings, and for a standard token, reduces the supply and available future registrations on that currency.
3) Minting of currency on demand by the identity of the currency as part of the “sendcurrency” command. This capability ends, and the currency identity has no minting ability after the “endblock” of the currency.
4) Burning a liquidity basket currency, but instead of affecting the supply/reserve ratio as normal burns do, the identity of a centralized currency can also burn currency to affect the reserve ratio weights of the currency. This capability ends, and the currency identity has no minting ability after the “endblock” of the currency.
5) v1.0.0 did not allow a decentralized non-liquidity token to register identities. v1.0.1 does.
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.1
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.1
Issues addressed Mainnet: v1.0.1 fixes an issue where original stakeguard outputs from 2 years ago or before may not show up in a wallet after rescan. Now they will again.
Testnet: In addition to fixing an issue discovered by @cautionfun on the current public testnet, this version also addresses an issue discovered during additional coverage testing on the oracle based, reversible rip-cord implementations to ensure the ability for the network to respond to any unexpected events quickly, safely, and without compromise to decentralization.
What’s New In addition to the full PBaaS protocol and all capabilities previously described, version 1.0.1 will also include some new capabilities that were previously not in the PBaaS protocol. The capabilities basically extend the idea of a centralized currency to include the ability to launch temporarily centralized currencies, including those that can sell identities. While a currency is centralized in this mode, fees and proceeds from the issuance of IDs go directly to the currency ID and are not burned into the currency itself. This is achieved by setting the “endblock” on a centralized currency launch of either a token or liquidity basket, enabling:
1) In v1.0.1, setting the endblock of a centralized currency causes all centralized capabilities of the controlling ID to end when the endblock is reached, converting it in whatever state it currently is into a decentralized currency with no special control over it by any identity on the network after that occurs.
2) Registering identities on a currency. When an identity is registered on a centralized currency, the fee for the registration is not burned into the currency, but sent directly to the identity of the currency. This is true for token or liquidity basket currencies. For decentralized currencies, fees are burned, which on a liquidity basket, puts them into the liquidity pool for all LPs to share in earnings, and for a standard token, reduces the supply and available future registrations on that currency.
3) Minting of currency on demand by the identity of the currency as part of the “sendcurrency” command. This capability ends, and the currency identity has no minting ability after the “endblock” of the currency.
4) Burning a liquidity basket currency, but instead of affecting the supply/reserve ratio as normal burns do, the identity of a centralized currency can also burn currency to affect the reserve ratio weights of the currency. This capability ends, and the currency identity has no minting ability after the “endblock” of the currency.
5) v1.0.0 did not allow a decentralized non-liquidity token to register identities. v1.0.1 does.
April 24, 2023, 02:19:39 AM
Announcing v1.0.0 - PBaaS Mainnet Upgrade, UPGRADE TO v1.0.0 OR LATER MANDATORY FOR CONTINUED MAINNET AND TESTNET USE AFTER MAY 21, 2023, EXPECTED BLOCK #2546600
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.0
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.0
What’s New This release delivers on every part of the vision (and most stretch goals) either described in the vision paper of June 2018 or ever planned for the PBaaS release. Thanks to the incredible combined efforts of so many people in the community ranging from development, companies and projects joining and their open contributions (Valu/Arkeytyp, CHIPS, vDEX, VaultAlert, cragslist, and more) to community members supporting users to helping educate others who can contribute as well, we have run these protocols now for years as we’ve improved them, and all of these capabilities will go live on the Verus mainnet May 21, 2023, with the activation expected targeting block 2546600. As a community, we’ve discussed what the Verus PBaaS protocol can do for years. Now that it has existed on testnet for as long as it has, only those who have either been part of those conversations or experienced it first hand have a real sense for how much better Verus PBaaS is as a solution for cross-chain, DeFi AMMs, decentralized markets, self-sovereign provable recoverable IDs, NFT capabilities, anti-phishing, anti-MEV, scale, or just about any of the challenges people have on crypto platforms today. In fact, as we prepare for activation of this protocol that enables so many new use cases for crypto, not to mention easy onboarding when entrepreneurs discover how to really leverage VerusIDs, PBaaS is so far beyond what people are experiencing on any crypto platform today that it has been easy to dismiss our community as describing the impossible.
Once we are live on mainnet and people can actually use all of this themselves, along with every project, chain and currency on the PBaaS network and EVERY ERC20 or ERC721 on Ethereum or even bridged to Ethereum, the truth of Verus will be self-evident, and those who build on Verus will more easily build faster, better, more secure apps and services with the possibility of provable identity + privacy, crowdfunded projects, businesses, economies, and public infrastructure efforts all seamlessly integrated into UIs that do not need business deals, permission, or any centralized infrastructure to connect services and users, enabling everyone to communicate in provable, private, or public ways that always include bidirectional, secure commerce of all kinds. This core capabilities of this release include (lots to learn to understand it all, but here’s a partial list):
1) Mainnet PBaaS Activation MAY 21, 2023, EXPECTED BLOCK #2546600: v1.0.0 is MANDATORY, meaning that you will need to upgrade to this release or a later version v1.0.0-x, before MAY 21, 2023 to stay reliably connected to mainnet. Testnet will also be reset within the next day, and this release will allow you to connect to the new testnet, which we see as a core development platform and staging area for the Verus PBaaS network and have no plans to reset in any foreseeable future.
2) Verus Intersystem Protocol (VIP) - Layer 0 Multichain and Inter-chain Protocol: To our knowledge, the VIP protocol is the only fully decentralized, provable cross-chain technology available on any network that is based on cryptographic proofs of each chain with optional witnesses to confirm chain state. From what we’ve been able to learn about LayerZero, Cosmos, Polkadot, Thorchain or others, VIP is different from (though closest in some ways to LayerZero), superior to, and more decentralized than all other cross-chain protocols we have seen. We can of course get into any level of discussion on the topic, but expect more descriptions and educational material to follow, now that the protocol was originally conceived of 5 years ago, and has been developed and tested/hardened for years.
3) VerusID Content Multimaps - Unlimited Provable Data for Every VerusID: With the PBaaS upgrade, VerusIDs gain a powerful new capability that can be used for social networking, voting, oracles, publishing any information, various forms of provable attestations, ratings, and much, much more. With the scalability of PBaaS and VerusID content multimaps together, the Verus PBaaS network becomes the most scalable, permissionless, provable source of human data from which AIs can learn about humanity in the world. We don’t believe anything else even comes close, and with the recent rise of AI, it feels great to have this come together as a core original goal at a very appropriate and important time in history.
4) Permissionless Chain, Token, and Liquidity Basket Currency Launches: Whether you are looking to crowdfund an effort in a manner much like Kickstarter or IndieGoGo, sell identities to which you expect to add value or that are sub-IDs of a very cool root ID, or launch an entirely new blockchain economy and blockchain that starts with all of the Verus technology and a bridge to Verus and Ethereum from day 1, Verus is probably the best platform for you. In fact, as we were planning for the next testnet and wanted to have our own version of DAI to use in the bridge, since we want only decentralized currencies in the live mainnet bridge, we used a command to launch a token on the old testnet, exported it and all its supply to Ethereum’s Goerli on the existing bridge, and that will be the DAI proxy/simulant that we will use on the new testnet. It saved us all some time, proving that Verus PBaaS will also be the easiest, most efficient way to launch even an Ethereum ERC20, whether that ERC20 represents a token, DeFi basket, or even another PBaaS blockchain
5) Decentralized Ethereum Bridge: Shortly after PBaaS activates on mainnet, the Ethereum bridge will launch as a decentralized gateway and 1:1 provably mapped currency called “vETH” on the Verus network, also available to all PBaaS chains. The Ethereum bridge will also include a 100% backed basket of 33% Verus, 33% Ethereum, and 33% DAI, which will have the following functions: a. Auto conversion of fees from Verus <-> Ethereum when sending cross chain, based on the on-chain conversion price in the liquidity basket Permissionless ability to register *.vETH IDs, which in addition to the normal sub-ID capability of creating a single token that has control over the ID and can be exported to Ethereum as an automatic ERC721 NFT, can alternately be used to create a “mapped currency”, which can be provably mapped 1:1 to any ERC20 currency on the Ethereum network by exporting it to the vETH bridge. Only Verus root IDs, and IDs of a gateway can create mapped currencies to a gateway. b. Decentralized, fair bridge launch. The vETH bridge will launch as other currencies, chains, and gateways can launch, including the bridge converter. When the bridge launches, the contracts will have a surplus of Verus that comes from the fees paid to launch the gateway. In the protocol, that surplus is first used to solve the chicken and egg problem of none of one currency on the other chain. The contracts will cover the Verus fees for all sends from Ethereum before the Bridge converter launches, the liquidity basket becomes active, and the bridge recognizes that launch. Once that happens, the remainder of ½ the fees (5000 VRSC) that are left over from the launch and did not get used to pay fees for people sending from Ethereum to Verus will be burned into the Bridge.vETH liquidity basket, benefiting all who participated in the launch equally.
6) The Verus Fee Pool and Rewards: Another technology and solution unique to Verus, the Verus Fee Pool technology goes live with PBaaS. What this means is that as people use the cross-chain, DeFi, or purchase/register IDs on the network, the miner or staker will put all fees into the on-chain “fee pool”, and then take 1/100th of the pool in addition to the block reward. This gives everyone incentive to still prioritize transactions based on fees, while preventing validators from gaming the fee system by washing fees-in vs. fees-out or working to reorg/rewind to capture a particularly juicy block reward. Instead, this technology aligns all validator incentives with the health/proper operation of the network and creates a circular on-chain economy that can last well beyond block rewards. For those who understand the challenges actual users have in crypto today, this release represents a historic move forward in public cryptographic networks and credibly and actually neutral infrastructure for society-wide human and AI collaboration and learning. As a community, this version really does realize the vision laid out in the original Verus Vision Paper, and at the same time provides much more than was described there. We are a community of individuals, and it is only because that is what we are that we have all arrived here together. The rest of the world is stuck on their Munchausen’s protocols, trying to figure out how to share the front-running and back-running spoils taken from users, but Verus activation gives them a better path forward.
As a community, we do not promise, we describe a shared vision and welcome contributors from everywhere. Now that we, as a community, have delivered on the original phases described in the first vision paper together, it is time for each of us to also consider what we might personally want to build or be part of building over this incredible, geoscale, ID-enabled, fully decentralized platform. Our next efforts across the community should be to realize the promise of this network in the use cases we create, use cases that we will have an advantage creating on Verus over any other platform because it really is that much better.
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v1.0.0
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v1.0.0
What’s New This release delivers on every part of the vision (and most stretch goals) either described in the vision paper of June 2018 or ever planned for the PBaaS release. Thanks to the incredible combined efforts of so many people in the community ranging from development, companies and projects joining and their open contributions (Valu/Arkeytyp, CHIPS, vDEX, VaultAlert, cragslist, and more) to community members supporting users to helping educate others who can contribute as well, we have run these protocols now for years as we’ve improved them, and all of these capabilities will go live on the Verus mainnet May 21, 2023, with the activation expected targeting block 2546600. As a community, we’ve discussed what the Verus PBaaS protocol can do for years. Now that it has existed on testnet for as long as it has, only those who have either been part of those conversations or experienced it first hand have a real sense for how much better Verus PBaaS is as a solution for cross-chain, DeFi AMMs, decentralized markets, self-sovereign provable recoverable IDs, NFT capabilities, anti-phishing, anti-MEV, scale, or just about any of the challenges people have on crypto platforms today. In fact, as we prepare for activation of this protocol that enables so many new use cases for crypto, not to mention easy onboarding when entrepreneurs discover how to really leverage VerusIDs, PBaaS is so far beyond what people are experiencing on any crypto platform today that it has been easy to dismiss our community as describing the impossible.
Once we are live on mainnet and people can actually use all of this themselves, along with every project, chain and currency on the PBaaS network and EVERY ERC20 or ERC721 on Ethereum or even bridged to Ethereum, the truth of Verus will be self-evident, and those who build on Verus will more easily build faster, better, more secure apps and services with the possibility of provable identity + privacy, crowdfunded projects, businesses, economies, and public infrastructure efforts all seamlessly integrated into UIs that do not need business deals, permission, or any centralized infrastructure to connect services and users, enabling everyone to communicate in provable, private, or public ways that always include bidirectional, secure commerce of all kinds. This core capabilities of this release include (lots to learn to understand it all, but here’s a partial list):
1) Mainnet PBaaS Activation MAY 21, 2023, EXPECTED BLOCK #2546600: v1.0.0 is MANDATORY, meaning that you will need to upgrade to this release or a later version v1.0.0-x, before MAY 21, 2023 to stay reliably connected to mainnet. Testnet will also be reset within the next day, and this release will allow you to connect to the new testnet, which we see as a core development platform and staging area for the Verus PBaaS network and have no plans to reset in any foreseeable future.
2) Verus Intersystem Protocol (VIP) - Layer 0 Multichain and Inter-chain Protocol: To our knowledge, the VIP protocol is the only fully decentralized, provable cross-chain technology available on any network that is based on cryptographic proofs of each chain with optional witnesses to confirm chain state. From what we’ve been able to learn about LayerZero, Cosmos, Polkadot, Thorchain or others, VIP is different from (though closest in some ways to LayerZero), superior to, and more decentralized than all other cross-chain protocols we have seen. We can of course get into any level of discussion on the topic, but expect more descriptions and educational material to follow, now that the protocol was originally conceived of 5 years ago, and has been developed and tested/hardened for years.
3) VerusID Content Multimaps - Unlimited Provable Data for Every VerusID: With the PBaaS upgrade, VerusIDs gain a powerful new capability that can be used for social networking, voting, oracles, publishing any information, various forms of provable attestations, ratings, and much, much more. With the scalability of PBaaS and VerusID content multimaps together, the Verus PBaaS network becomes the most scalable, permissionless, provable source of human data from which AIs can learn about humanity in the world. We don’t believe anything else even comes close, and with the recent rise of AI, it feels great to have this come together as a core original goal at a very appropriate and important time in history.
4) Permissionless Chain, Token, and Liquidity Basket Currency Launches: Whether you are looking to crowdfund an effort in a manner much like Kickstarter or IndieGoGo, sell identities to which you expect to add value or that are sub-IDs of a very cool root ID, or launch an entirely new blockchain economy and blockchain that starts with all of the Verus technology and a bridge to Verus and Ethereum from day 1, Verus is probably the best platform for you. In fact, as we were planning for the next testnet and wanted to have our own version of DAI to use in the bridge, since we want only decentralized currencies in the live mainnet bridge, we used a command to launch a token on the old testnet, exported it and all its supply to Ethereum’s Goerli on the existing bridge, and that will be the DAI proxy/simulant that we will use on the new testnet. It saved us all some time, proving that Verus PBaaS will also be the easiest, most efficient way to launch even an Ethereum ERC20, whether that ERC20 represents a token, DeFi basket, or even another PBaaS blockchain
5) Decentralized Ethereum Bridge: Shortly after PBaaS activates on mainnet, the Ethereum bridge will launch as a decentralized gateway and 1:1 provably mapped currency called “vETH” on the Verus network, also available to all PBaaS chains. The Ethereum bridge will also include a 100% backed basket of 33% Verus, 33% Ethereum, and 33% DAI, which will have the following functions: a. Auto conversion of fees from Verus <-> Ethereum when sending cross chain, based on the on-chain conversion price in the liquidity basket Permissionless ability to register *.vETH IDs, which in addition to the normal sub-ID capability of creating a single token that has control over the ID and can be exported to Ethereum as an automatic ERC721 NFT, can alternately be used to create a “mapped currency”, which can be provably mapped 1:1 to any ERC20 currency on the Ethereum network by exporting it to the vETH bridge. Only Verus root IDs, and IDs of a gateway can create mapped currencies to a gateway. b. Decentralized, fair bridge launch. The vETH bridge will launch as other currencies, chains, and gateways can launch, including the bridge converter. When the bridge launches, the contracts will have a surplus of Verus that comes from the fees paid to launch the gateway. In the protocol, that surplus is first used to solve the chicken and egg problem of none of one currency on the other chain. The contracts will cover the Verus fees for all sends from Ethereum before the Bridge converter launches, the liquidity basket becomes active, and the bridge recognizes that launch. Once that happens, the remainder of ½ the fees (5000 VRSC) that are left over from the launch and did not get used to pay fees for people sending from Ethereum to Verus will be burned into the Bridge.vETH liquidity basket, benefiting all who participated in the launch equally.
6) The Verus Fee Pool and Rewards: Another technology and solution unique to Verus, the Verus Fee Pool technology goes live with PBaaS. What this means is that as people use the cross-chain, DeFi, or purchase/register IDs on the network, the miner or staker will put all fees into the on-chain “fee pool”, and then take 1/100th of the pool in addition to the block reward. This gives everyone incentive to still prioritize transactions based on fees, while preventing validators from gaming the fee system by washing fees-in vs. fees-out or working to reorg/rewind to capture a particularly juicy block reward. Instead, this technology aligns all validator incentives with the health/proper operation of the network and creates a circular on-chain economy that can last well beyond block rewards. For those who understand the challenges actual users have in crypto today, this release represents a historic move forward in public cryptographic networks and credibly and actually neutral infrastructure for society-wide human and AI collaboration and learning. As a community, this version really does realize the vision laid out in the original Verus Vision Paper, and at the same time provides much more than was described there. We are a community of individuals, and it is only because that is what we are that we have all arrived here together. The rest of the world is stuck on their Munchausen’s protocols, trying to figure out how to share the front-running and back-running spoils taken from users, but Verus activation gives them a better path forward.
As a community, we do not promise, we describe a shared vision and welcome contributors from everywhere. Now that we, as a community, have delivered on the original phases described in the first vision paper together, it is time for each of us to also consider what we might personally want to build or be part of building over this incredible, geoscale, ID-enabled, fully decentralized platform. Our next efforts across the community should be to realize the promise of this network in the use cases we create, use cases that we will have an advantage creating on Verus over any other platform because it really is that much better.
March 30, 2023, 06:15:55 PM
Announcing v0.9.9-5 - CRITICAL PRIVACY FIX PARSING FRIENDLY PRIVATE NAMES, CRITICAL UPDATE FOR RELIABLE TESTNET OPERATION Mainnet Changes - Privacy Fix and Wallet Hardening v0.9.9-5
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9-5
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9-5
Fixes an issue introduced in v0.9.9 during the ID name hardening work that prevented parsing id@:private to the z-address of id@ when running a native node. Instead, such an address parsed to the main id@. Since this issue could impact on-chain privacy of someone intending to send to or from a private address and using friendly names, we are considering this a critical privacy release. This version also prevents the wallet from crediting transactions that can be constructed to make a burn look like a spendable output, ensuring that unspendable funds are not added to a wallet or address balance. @Alright, who has been focusing on Verus security testing, reported a way that someone might create such an output, and we appreciate that it is before we have ever seen such transactions on the public or test networks. Thanks @Alright for the report and discretion that helps keep them off the network(s) altogether! We recommend that everyone update as soon as possible to version 0.9.9-5 or later. We are working towards the mainnet PBaaS upgrade version 1.0.0, but we cannot put a specific date beyond on its release.
What’s New for TestNet This release fixes hopefully the last remaining issue that was causing testnet users to experience sync issues on PBaaS chains. There are no other significant changes.
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9-5
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9-5
Fixes an issue introduced in v0.9.9 during the ID name hardening work that prevented parsing id@:private to the z-address of id@ when running a native node. Instead, such an address parsed to the main id@. Since this issue could impact on-chain privacy of someone intending to send to or from a private address and using friendly names, we are considering this a critical privacy release. This version also prevents the wallet from crediting transactions that can be constructed to make a burn look like a spendable output, ensuring that unspendable funds are not added to a wallet or address balance. @Alright, who has been focusing on Verus security testing, reported a way that someone might create such an output, and we appreciate that it is before we have ever seen such transactions on the public or test networks. Thanks @Alright for the report and discretion that helps keep them off the network(s) altogether! We recommend that everyone update as soon as possible to version 0.9.9-5 or later. We are working towards the mainnet PBaaS upgrade version 1.0.0, but we cannot put a specific date beyond on its release.
What’s New for TestNet This release fixes hopefully the last remaining issue that was causing testnet users to experience sync issues on PBaaS chains. There are no other significant changes.
March 30, 2023, 06:11:34 PM
We are excited to announce the release of Verus Mobile version 0.3.0-27!
Android Build: https://github.com/VerusCoin/Verus-Mobile/releases/download/v0.3.0-27/VerusMobile-0.3.0-27.apk
iOS Testflight Link: https://testflight.apple.com/join/ZS43lYcw
This update brings many improvements and features to the app to enhance your user experience. This release is also a milestone for Verus Mobile, as it is the first release candidate for our App Store/Play Store release, hopefully following soon after this test release. Here are some of the highlights: • Redesigned app onboarding process: We've modernised the user interface and added helpful tools to minimise profile creating difficulty, like the 24-word seed import helper.
This makes it easier for new users to get started with Verus Mobile.
• Updated VerusID login protocol: We've updated various aspects of the VerusID login protocol to ready it for mainstream app-store release.
• Disabled deprecated Wyre features: Wyre features are now deprecated by default and can be re-enabled if desired in profile settings.
• Increased performance: We've decreased the number of web requests to improve app performance.
• Redesigned wallet home screen: We've redesigned the wallet home screen to use draggable widgets, allowing for customisation and modularity for future features.
As we are very close to our first App/Play store release, we encourage all users to submit any feedback or test data in the verus-mobile-wallet channel. Your feedback is crucial in helping us improve the app and ensure that it meets your needs. Thank you for your continued support and feedback.
Android Build: https://github.com/VerusCoin/Verus-Mobile/releases/download/v0.3.0-27/VerusMobile-0.3.0-27.apk
iOS Testflight Link: https://testflight.apple.com/join/ZS43lYcw
This update brings many improvements and features to the app to enhance your user experience. This release is also a milestone for Verus Mobile, as it is the first release candidate for our App Store/Play Store release, hopefully following soon after this test release. Here are some of the highlights: • Redesigned app onboarding process: We've modernised the user interface and added helpful tools to minimise profile creating difficulty, like the 24-word seed import helper.
This makes it easier for new users to get started with Verus Mobile.
• Updated VerusID login protocol: We've updated various aspects of the VerusID login protocol to ready it for mainstream app-store release.
• Disabled deprecated Wyre features: Wyre features are now deprecated by default and can be re-enabled if desired in profile settings.
• Increased performance: We've decreased the number of web requests to improve app performance.
• Redesigned wallet home screen: We've redesigned the wallet home screen to use draggable widgets, allowing for customisation and modularity for future features.
As we are very close to our first App/Play store release, we encourage all users to submit any feedback or test data in the verus-mobile-wallet channel. Your feedback is crucial in helping us improve the app and ensure that it meets your needs. Thank you for your continued support and feedback.
March 27, 2023, 07:14:01 AM
Announcing v0.9.9-4 - RECOMMENDED FOR MAINNET, MANDATORY UPDATE FOR RELIABLE TESTNET OPERATION Mainnet Changes - low level stakeguard improvements, no functional changes What’s New for TestNet
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9-4
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9-4
This release fixes an issue that was causing testnet users to experience sync issues on chains that had more than one oracle upgrade for the same capability activated. There are no other significant changes.
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9-4
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9-4
This release fixes an issue that was causing testnet users to experience sync issues on chains that had more than one oracle upgrade for the same capability activated. There are no other significant changes.
March 23, 2023, 05:20:16 PM
Announcing v0.9.9-3 - FULLY OPTIONAL UPDATE FOR MAINNET, MANDATORY UPDATE FOR CONTINUED TESTNET OPERATION Mainnet Changes - no protocol changes V0.9.9-3 introduces the prunespentwallettransactions CLI command and RPC API, providing a method for holders on testnet or mainnet of very large wallets to prune older spent transactions, which can improve performance for wallets that may be slowing down due to size. There are no mainnet protocol changes in v0.9.9-3 over the prior release.
What’s New for TestNet This release includes an activation that allows a major upgrade to the testnet Ethereum bridge contracts that is both not expected to be needed again on testnet and not ever needed on mainnet with the new contract upgrade model. This upgrade should clear all known issues on the bridge to Goerli, meaning any remaining bridge transactions will be delivered, and the ETH bridge should then be fully functional. The Path for PBaaS to Mainnet This testnet has actually been through a lot already, more than we expected before mainnet, and this last experience, along with its full restoration of cross-chain and all function has been very useful and was the impetus for the Verus Oracle Notification technology. In the process of getting here, we implemented the necessary changes and fixes to get everything back on track, but we also have remnants of these events in the daemon, and on the final protocol, these are there to enable compatibility with the history of testnet, not because we need these upgrades on mainnet PBaaS. It gave us experience, increased confidence, and pushed us to develop a fast, decentralized network response capability. At the same time, it would be best for our code base, both on the Verus side and in the ETH contracts if that testnet history is removed from the code before mainnet activation. Doing so would make the next upgrade incompatible with today’s testnet and its earlier history. As a result, we have decided that we will create one final testnet, but this time, we would do it a little differently than in the past. We will extend the pre-PBaaS upgrade on the existing testnet to a future date via the oracles. If you have started a chain and control the default oracle on any chain, please check the pbaas-development channel for instructions on setting your oracle to extend the upgrade. We will leave the current testnet running and fully functional, as we prepare the next release, which we expect to be ready for a mainnet PBaaS activation. We will effectively abandon this testnet and leave it running long enough to overlap with the next and final testnet instance before PBaaS release. You should be able to actually send currencies over from the first testnet to the second via Ethereum’s Goerli testnet, even map some VRSCTEST-CLASSIC or something else through the bridge, but we do not intend to update that daemon again, or continue to run nodes or notaries on the old test network for more than a couple weeks after the new testnet goes live. Thanks for all your help and contributions, both already made and those to come for this historic upcoming release!
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9-3
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9-3
What’s New for TestNet This release includes an activation that allows a major upgrade to the testnet Ethereum bridge contracts that is both not expected to be needed again on testnet and not ever needed on mainnet with the new contract upgrade model. This upgrade should clear all known issues on the bridge to Goerli, meaning any remaining bridge transactions will be delivered, and the ETH bridge should then be fully functional. The Path for PBaaS to Mainnet This testnet has actually been through a lot already, more than we expected before mainnet, and this last experience, along with its full restoration of cross-chain and all function has been very useful and was the impetus for the Verus Oracle Notification technology. In the process of getting here, we implemented the necessary changes and fixes to get everything back on track, but we also have remnants of these events in the daemon, and on the final protocol, these are there to enable compatibility with the history of testnet, not because we need these upgrades on mainnet PBaaS. It gave us experience, increased confidence, and pushed us to develop a fast, decentralized network response capability. At the same time, it would be best for our code base, both on the Verus side and in the ETH contracts if that testnet history is removed from the code before mainnet activation. Doing so would make the next upgrade incompatible with today’s testnet and its earlier history. As a result, we have decided that we will create one final testnet, but this time, we would do it a little differently than in the past. We will extend the pre-PBaaS upgrade on the existing testnet to a future date via the oracles. If you have started a chain and control the default oracle on any chain, please check the pbaas-development channel for instructions on setting your oracle to extend the upgrade. We will leave the current testnet running and fully functional, as we prepare the next release, which we expect to be ready for a mainnet PBaaS activation. We will effectively abandon this testnet and leave it running long enough to overlap with the next and final testnet instance before PBaaS release. You should be able to actually send currencies over from the first testnet to the second via Ethereum’s Goerli testnet, even map some VRSCTEST-CLASSIC or something else through the bridge, but we do not intend to update that daemon again, or continue to run nodes or notaries on the old test network for more than a couple weeks after the new testnet goes live. Thanks for all your help and contributions, both already made and those to come for this historic upcoming release!
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9-3
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9-3
March 16, 2023, 05:18:59 AM
Announcing v0.9.9-2 - CRITICAL SECURITY UPDATE FOR MAINNET AND REQUIRED UPDATE TO RESUME SUCCESSFUL MERGE MINING NOTARIZATION ON TESTNET
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9-2
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9-2
Important Mainnet Security Updates v0.9.9-2 introduces new mitigation code for the Rab13s vulnerability, announced by Halbourne 3 days ago as a zero day vulnerability in over 280 blockchains, including Zcash and Verus, that could allow someone to attack and bring down specific nodes that they may target through exhausting the node’s resources.
The Verus fix adapts a fix implemented in Zcash that also does a better job of preserving privacy while gossiping transactions around the network by making it harder to track their node of origin via listening nodes. This release also includes an important update of the OpenSSL library, which Verus uses for encrypted node connections and addresses a buffer overflow vulnerability in that library.
What’s New for TestNet This release re-enables cross-chain notarization, and represents the completion of a great deal of learning from the first roll out of auto notarization. Basically, we encountered two issues:
1) There was a notarization bug in a significantly updated approach that caused notarizations to fork, effectively simulating a worst case, unmitigated attack on the notarization system. While that did not cause the system to fail per se, it resulted in the generation of many perceived, although not real, notarization forks on the network.
2) Due to our effort to err on the side of more evidence than we believed was sufficient with auto notarization, then optimize to reduce the proofs required, the protocol was simply taking too long and generating too large proofs to be reasonable, required, or what we need on mainnet in any real scenario.
As a result, we will take a few days to change some parameters in the auto notarization protocol that will both reduce the total and maximum amount of proof required, as well as provide a sufficient level of cryptographic proof, similar in strength to the current proof model with more efficient and selective proof choices. We don’t expect this important step to take long, and until then, we will leave testnet on the pre-PBaaS to mainnet preparatory state. The good news is that since we have the new Verus Notification Oracle technology, we can enable everyone running on the current testnet to remain connected as all cross-chain transactions to and from PBaaS chains will resume flowing.
We are still seeing an error in BridgeKeeper, but since this release includes a mainnet security update and addresses all other known issues on testnet, we’ll release this immediately and update Bridgekeeper as soon as possible. In order to merge mine PBaaS chains with Verus or the Ethereum bridge to Goerli going forward, you will need to update to v0.9.9-2, which everyone should run for mainnet anyhow.
Once you update, please feel free to resume merge mining all PBaaS chains and Verus. You will need to wait for the BridgeKeeper update to be able to merge mine and stake with Ethereum’s Goerli. Thanks for all your testing! We’ve learned a great deal from this upgrade, and although it may feel like a delay that we took the time to learn and address it in place on the public network before moving on, this learning and consequent hardening will ensure the mainnet release will be more hardened than ever. Next steps are to upgrade auto notarization to be resilient to anything like this level of buildup over weeks automatically and prepare the mainnet release. Join us in testing everything in the pbaas-development channel. Contribute as you learn and build, and let's all make history together!
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9-2
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9-2
Important Mainnet Security Updates v0.9.9-2 introduces new mitigation code for the Rab13s vulnerability, announced by Halbourne 3 days ago as a zero day vulnerability in over 280 blockchains, including Zcash and Verus, that could allow someone to attack and bring down specific nodes that they may target through exhausting the node’s resources.
The Verus fix adapts a fix implemented in Zcash that also does a better job of preserving privacy while gossiping transactions around the network by making it harder to track their node of origin via listening nodes. This release also includes an important update of the OpenSSL library, which Verus uses for encrypted node connections and addresses a buffer overflow vulnerability in that library.
What’s New for TestNet This release re-enables cross-chain notarization, and represents the completion of a great deal of learning from the first roll out of auto notarization. Basically, we encountered two issues:
1) There was a notarization bug in a significantly updated approach that caused notarizations to fork, effectively simulating a worst case, unmitigated attack on the notarization system. While that did not cause the system to fail per se, it resulted in the generation of many perceived, although not real, notarization forks on the network.
2) Due to our effort to err on the side of more evidence than we believed was sufficient with auto notarization, then optimize to reduce the proofs required, the protocol was simply taking too long and generating too large proofs to be reasonable, required, or what we need on mainnet in any real scenario.
As a result, we will take a few days to change some parameters in the auto notarization protocol that will both reduce the total and maximum amount of proof required, as well as provide a sufficient level of cryptographic proof, similar in strength to the current proof model with more efficient and selective proof choices. We don’t expect this important step to take long, and until then, we will leave testnet on the pre-PBaaS to mainnet preparatory state. The good news is that since we have the new Verus Notification Oracle technology, we can enable everyone running on the current testnet to remain connected as all cross-chain transactions to and from PBaaS chains will resume flowing.
We are still seeing an error in BridgeKeeper, but since this release includes a mainnet security update and addresses all other known issues on testnet, we’ll release this immediately and update Bridgekeeper as soon as possible. In order to merge mine PBaaS chains with Verus or the Ethereum bridge to Goerli going forward, you will need to update to v0.9.9-2, which everyone should run for mainnet anyhow.
Once you update, please feel free to resume merge mining all PBaaS chains and Verus. You will need to wait for the BridgeKeeper update to be able to merge mine and stake with Ethereum’s Goerli. Thanks for all your testing! We’ve learned a great deal from this upgrade, and although it may feel like a delay that we took the time to learn and address it in place on the public network before moving on, this learning and consequent hardening will ensure the mainnet release will be more hardened than ever. Next steps are to upgrade auto notarization to be resilient to anything like this level of buildup over weeks automatically and prepare the mainnet release. Join us in testing everything in the pbaas-development channel. Contribute as you learn and build, and let's all make history together!
March 10, 2023, 04:32:46 PM
Announcing v0.9.9 - PBaaS Mainnet Preparation Release, MANDATORY FOR MAINNET AND CONTINUED TESTNET USE
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9
What’s New
There is so much new and important in v0.9.9, and we are so close to the mainnet PBaaS release that this is a hard announcement to keep to a digestible size. Key points:
Preparing for #LaunchPBaaS: v0.9.9 is MANDATORY, meaning that you will need to upgrade to this release ASAP to stay reliably connected to mainnet after the first preparatory PBaaS upgrade is triggered, both for testnet and mainnet. While the current deadline for being upgraded is in 1 week, it is a soft fork that we would like to activate as soon as possible, and if we can believe that we have more than 50% of the validating network updated earlier than 1 week, we will trigger the activation with our Oracle Notification Technology described in #2. (Mainnet + Testnet)
Enabling Seamless Decentralized Network Upgrades: This release includes a Verus invention of consensus-capable oracle notifications built into the core protocol, which enable dynamic coordinated consensus changes that can be triggered at a time decided after the actual release which enables them, all without any compromise on decentralization. The Verus Community may decide that we are ready to go earlier than one week on this upgrade and activate it, even before its scheduled time. The good news is that this first test upgrade will primarily affect testnet and prepare for the mainnet PBaaS upgrade, so it is a perfect test case for a mainnet test run before we #LaunchPBaaS. This release actually has the ability to upgrade mainnet to PBaaS, but we believe it is prudent to have at least some time on this new protocol on testnet before the v1.0 release, which will upgrade mainnet. If we make no additional changes to the protocol in this release, which we do not intend to do at this time, this version may be able to follow the v1.0 upgrade. If we determine that it cannot, the oracle upgrade technology will enable the daemon to recognize that it is not capable and request that the user upgrade to a newer version without requiring a bootstrap for the upgrade. (Mainnet + Testnet)
This upgrade fixes all known testnet issues with no reset: Using v0.9.9, you should be able to sync fully and resume all cross-chain operations on the Verus test network, if you were not able to perform cross-chain operations or sync to the network on the prior version. As mentioned, someone seems to have mined with an intermediate version along the way on testnet and made the network unavailable without a bootstrap on the older daemon. This version should fix that issue as well as any cross-chain difficulties. Auto-notarization will be enabled on testnet in sync when the testfork executes. Until then, all witnessed cross-chain operations should be able to resume, if they have had difficulty. (Testnet until the #LaunchPBaaS release)
Bridging Blockchain Networks Without Witnesses: v0.9.9 is the first release of any blockchain protocol anywhere that we know of which enables cryptographically provable, cross-chain bridging across Verus and all PBaaS and other connected blockchains in the network, either combined with or independent of the need for notary witnesses. With notary witnesses, cross-chain transactions complete faster, but they are also checked against cryptographic evidence, making it difficult to impossible for anyone, including notary witnesses to take any action, even colluding with validators that would go against the wishes of the most chain power. We have been referring to this new cross-chain consensus technology as “auto-notarization”, as that is what it actually is, but it would also be accurate to call it Proof of Proof of Power, as that is how it works. For purposes of ensuring everyone understands the state of the technology, it is fully functional and we have taken great care to ensure it is sufficiently secure, but we have not yet had the protocol proven to an academic standard. Because of that, while it provides a security fall-back against misbehaving notary witnesses and will be fully functional and we believe sufficiently secure without notary witnesses on release, we currently recommend toconsider the protocol unproven at this time and that any serious PBaaS chains be launched with operational notary witnesses until further notice.
Using “notarizationprotocol”:1, which is also the default, a chain launch can specify notary witnesses that will be used when they do their job. Even if they stop witnessing for any reason, the protocol will fail-over to auto-notarization, ensuring that cross-chain transactions still function as expected, even if just for people to move their assets to another blockchain, although significantly more slowly and based solely on cryptographic proof and challenge resolution between merge miners and stakers. This cross-chain proof and challenge protocol operates even when witnesses are also operating and if miners and stakers continue to prove a more powerful chain than the one witnesses represent, the most powerful chain can still be confirmed. (Testnet until the #LaunchPBaaS release) Expanding L1 VerusID APIs: This release provides a major enhancement to the identity content multimap support with two new APIs, getidentityhistory and getidentitycontent that provide real-time mempool access and also introduce self-sovereign delete operations to identity content that can be used by applications, making it easy for applications to index, organize, and aggregate an unlimited amount of user content referenced by an identity and made available to the application. This is the technology we used for oracle upgrade notifications, as all of this is available at L1, making it possible to imagine future protocols that can deal smoothly with diverse community opinions worldwide, but always respect the sovereignty and decisions of all members on the network. (Testnet until the #LaunchPBaaS release)
Introducing Restricted VerusID Staking for PBaaS Chains: This release enables the stretch goal of restricted ID staking as an option for launching PBaaS chains. This option means that on such a PBaaS chain, only funds controlled by IDs with a parent of that PBaaS chain may stake blocks on that chain. When combined with restricted forms of ID issuance, whether approval or referral required and/or referral rewards, this capability opens up an entire new area for public/private blockchains and applications, as well as government, voting security, corporate, or organizational use cases.(Testnet until the #LaunchPBaaS release)
v0.9.9 represents the culmination of years of vision and work from across the entire community, and everyone who has been involved and contributed at all in any area over the last 5 years helped us get here today. From my perspective, I believe this represents a bigger potential benefit to the world than all of my prior professional efforts combined.
CLI release: https://github.com/VerusCoin/VerusCoin/releases/tag/v0.9.9
GUI release: https://github.com/VerusCoin/Verus-Desktop/releases/tag/v0.9.9
What’s New
There is so much new and important in v0.9.9, and we are so close to the mainnet PBaaS release that this is a hard announcement to keep to a digestible size. Key points:
Preparing for #LaunchPBaaS: v0.9.9 is MANDATORY, meaning that you will need to upgrade to this release ASAP to stay reliably connected to mainnet after the first preparatory PBaaS upgrade is triggered, both for testnet and mainnet. While the current deadline for being upgraded is in 1 week, it is a soft fork that we would like to activate as soon as possible, and if we can believe that we have more than 50% of the validating network updated earlier than 1 week, we will trigger the activation with our Oracle Notification Technology described in #2. (Mainnet + Testnet)
Enabling Seamless Decentralized Network Upgrades: This release includes a Verus invention of consensus-capable oracle notifications built into the core protocol, which enable dynamic coordinated consensus changes that can be triggered at a time decided after the actual release which enables them, all without any compromise on decentralization. The Verus Community may decide that we are ready to go earlier than one week on this upgrade and activate it, even before its scheduled time. The good news is that this first test upgrade will primarily affect testnet and prepare for the mainnet PBaaS upgrade, so it is a perfect test case for a mainnet test run before we #LaunchPBaaS. This release actually has the ability to upgrade mainnet to PBaaS, but we believe it is prudent to have at least some time on this new protocol on testnet before the v1.0 release, which will upgrade mainnet. If we make no additional changes to the protocol in this release, which we do not intend to do at this time, this version may be able to follow the v1.0 upgrade. If we determine that it cannot, the oracle upgrade technology will enable the daemon to recognize that it is not capable and request that the user upgrade to a newer version without requiring a bootstrap for the upgrade. (Mainnet + Testnet)
This upgrade fixes all known testnet issues with no reset: Using v0.9.9, you should be able to sync fully and resume all cross-chain operations on the Verus test network, if you were not able to perform cross-chain operations or sync to the network on the prior version. As mentioned, someone seems to have mined with an intermediate version along the way on testnet and made the network unavailable without a bootstrap on the older daemon. This version should fix that issue as well as any cross-chain difficulties. Auto-notarization will be enabled on testnet in sync when the testfork executes. Until then, all witnessed cross-chain operations should be able to resume, if they have had difficulty. (Testnet until the #LaunchPBaaS release)
Bridging Blockchain Networks Without Witnesses: v0.9.9 is the first release of any blockchain protocol anywhere that we know of which enables cryptographically provable, cross-chain bridging across Verus and all PBaaS and other connected blockchains in the network, either combined with or independent of the need for notary witnesses. With notary witnesses, cross-chain transactions complete faster, but they are also checked against cryptographic evidence, making it difficult to impossible for anyone, including notary witnesses to take any action, even colluding with validators that would go against the wishes of the most chain power. We have been referring to this new cross-chain consensus technology as “auto-notarization”, as that is what it actually is, but it would also be accurate to call it Proof of Proof of Power, as that is how it works. For purposes of ensuring everyone understands the state of the technology, it is fully functional and we have taken great care to ensure it is sufficiently secure, but we have not yet had the protocol proven to an academic standard. Because of that, while it provides a security fall-back against misbehaving notary witnesses and will be fully functional and we believe sufficiently secure without notary witnesses on release, we currently recommend toconsider the protocol unproven at this time and that any serious PBaaS chains be launched with operational notary witnesses until further notice.
Using “notarizationprotocol”:1, which is also the default, a chain launch can specify notary witnesses that will be used when they do their job. Even if they stop witnessing for any reason, the protocol will fail-over to auto-notarization, ensuring that cross-chain transactions still function as expected, even if just for people to move their assets to another blockchain, although significantly more slowly and based solely on cryptographic proof and challenge resolution between merge miners and stakers. This cross-chain proof and challenge protocol operates even when witnesses are also operating and if miners and stakers continue to prove a more powerful chain than the one witnesses represent, the most powerful chain can still be confirmed. (Testnet until the #LaunchPBaaS release) Expanding L1 VerusID APIs: This release provides a major enhancement to the identity content multimap support with two new APIs, getidentityhistory and getidentitycontent that provide real-time mempool access and also introduce self-sovereign delete operations to identity content that can be used by applications, making it easy for applications to index, organize, and aggregate an unlimited amount of user content referenced by an identity and made available to the application. This is the technology we used for oracle upgrade notifications, as all of this is available at L1, making it possible to imagine future protocols that can deal smoothly with diverse community opinions worldwide, but always respect the sovereignty and decisions of all members on the network. (Testnet until the #LaunchPBaaS release)
Introducing Restricted VerusID Staking for PBaaS Chains: This release enables the stretch goal of restricted ID staking as an option for launching PBaaS chains. This option means that on such a PBaaS chain, only funds controlled by IDs with a parent of that PBaaS chain may stake blocks on that chain. When combined with restricted forms of ID issuance, whether approval or referral required and/or referral rewards, this capability opens up an entire new area for public/private blockchains and applications, as well as government, voting security, corporate, or organizational use cases.(Testnet until the #LaunchPBaaS release)
v0.9.9 represents the culmination of years of vision and work from across the entire community, and everyone who has been involved and contributed at all in any area over the last 5 years helped us get here today. From my perspective, I believe this represents a bigger potential benefit to the world than all of my prior professional efforts combined.
March 07, 2023, 09:44:06 PM
Verus has technological innovations in many encryption fields. However, because it is a project without ICO, completely decentralized, and not controlled by bookmakers, not many people know and understand it. Because it does not have enough capital to promote in the market.
March 01, 2023, 06:37:18 PM
An article for verus.
Building a More Interoperable Future with Verus PBaaS & Proof of Power
https://blockster.com/building-a-more-interoperable-future-with-verus-pbaas-and-proof-of-power
Building a More Interoperable Future with Verus PBaaS & Proof of Power
https://blockster.com/building-a-more-interoperable-future-with-verus-pbaas-and-proof-of-power
Jump to: