*FOR CLARIFICATION TO OTHER COIN COMMUNITIES: BitGreen IS NOT a client of Han/Team Lunar. The BitGreen update we reference below took place last week, PRIOR to his search for answers from other blockchain communities.**
As are many stories circulating now about the current situation regarding chain vulnerabilities — we want to clarify a few things about this ongoing situation which has gained significant press coverage.
First of all: Coins across all chains are safe, and no user funds are at risk on because of this vulnerability. The only thing that has happened is that an exploiter has been abusing a bug to get significantly more stakes then he/she should be able to. This was occurring on the BITG chain, PivX chain, and likely most other PivX based blockchains.
First, let’s see the vulnerability in action. Begin by taking a look at this a cluster of PivX addresses: https://chainz.cryptoid.info/pivx/wallet.dws?1047385.htm
Let’s look at their behavior. These addresses send transactions to themselves constantly, often switching to new/other addresses to obfuscate their movements. We can assume this is likely an attempt to hide their malicious behavior. These addresses all have less than 150 coins, however they stake often. This should be impossible, because the average stake-weight on PivX hovers between 9k and 12k. In other words, 100 coins requires 100 days to get a weight of 10k; the average weight to stake. PoS 3.0 is not 100% evenly distributed, and there is a multitude of information out there detailing these specifics. This is a simplistic calculation— but for the purposes of this argument, it is sufficient. To summarize, given all known assumptions about PoS randomization, it is sufficient to say that the amount of stakes these addresses are getting is not normal. It should be statistically impossible.
The observed attack pattern looks like the one described in this article: https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806 under Stake Amplification. The exact vulnerabilities described here should have been fixed in PivX, and all the forks that pulled in its code.
This discovery has sparked contentious discussions over the past 24 hours. So, how are the exploiters abusing the vulnerability? We’re not entirely sure as of yet. It could be a manipulated wallet that takes out some of the self checks that are not in consensus, containing code to take advantage of a weakness in PoS instead. It could be a completely different attack vector. Our lead blockchain developer — Konez2k, had an emergency meeting with the Peercoin developers today. Upon further investigation, the developers determined that Peercoin, which is the basis for PoS 3.0 (but has moved to PoS 5.0 now), is NOT vulnerable to this exploit (at least on the first pass investigation). The truth is that we do not know what enabled this exploiter to conduct this attack. We have taken immediate action to avoid the problem, and in the meantime, the BitGreen team has stopped investigating the issue. We are moving to a code base which is not vulnerable to the exploit.
BitGreen noticed the attack and immediately pushed a hard fork with a few code updates to stop the exploiters. We identified some of the attackers’ coins and blocked them in the process as well. To successfully fork without further damage, we had all exchanges go into maintenance — and they are beginning to come back online as they update their wallets. To be clear: the exchanges were not put into maintenance because of the exploit— but because we needed to restrict coin supply movements and issue a timely hard fork without any users losing funds by depositing or withdrawling from an exchange without the updated wallet.
This was an emergency situation, the likes of which we avoid at all costs. This required a quick reaction and is not how updates are typically issued. This plan of action was taken because the fork we were already planning is not yet tested. In order to issue the new fork, we will require some additional time for internal testing. For this reason, we’ve enabled a temporary fork which will serve as a maintenance period.
We want to give a special thanks is due to LFE from coinexplorer.net, whose vast database made this investigation process smooth and navigable — rather than manually combing our own chain with scripts.
BitGreen is not moving to DASH
Before the aforementioned issues came to public light, the BitGreen team had already decided and began to integrate the new, cutting-edge Bitcoin Core codebase. This update will provide a more stable network overall, and it will allow us to implement many new features which we will be required for our utility integrations related to incentivizing energy efficiency and sustainability.
We identified, but do not intend to attempt to “solve” this security flaw which we have observed within the Proof of Stake implementation. We took immediate action to protect coin holders. Instead of waiting around —while the a malicious party managed to attain more and more coins — we protected our community by first increasing the total staking weight by encouraging community members to stake, and then implementing a series of small code changes. Both plans were highly effective in preventing and slowing the exploiters. The main goal of our action was to minimize the effects of the exploiters until we moved to the more stable Bitcoin/Peercoin codebase in the next few weeks.
So, to clarify: BitGreen is not moving to a DASH codebase. BitGreen is moving to a “DASH-like” deterministic Masternode system, using the consensus system in the latest Bitcoin core update. This integration is being developed and managed by our lead blockchain developer, Konez2k. The development on this new integration away from PivX came before we discovered the exploit. We are switching to a new masternode system because the current version can, under certain circumstances, cause chain splits due to different wallets having different node sync lists. BitGreen experienced two of those in quick succession in the past year, which is when we made the decision to begin development of the new BitGreen codebase. In any case, our development team sees moving away from the PivX codebase as a clear next step for BitGreen.
The Commented Out Code Argument
On reddit, there are claims that this attack on BitGreen was only possible because there are few lines of commented out code. These lines of code only check for the stakeage. Although our codebase change made this vulnerability easy to abuse on BitGreen, it did not enable the attack. Our change actually brought light to a situation which was already happening on PivX.
The “FUD Wars”
At BitGreen we don’t believe blaming any party is prudent, especially when the real goal is to find the cause of this exploit and prevent it from happening. There many news outlets and blogs picking up this story. Most stories blamed PivX for this exploit —but this was never the intent of the BitGreen development team. In identifying the problem, we only seek the solution. That being said, PivX and BitGreen have not had an open line of communication in the past. We received zero development support or communication from their team. To the best of our knowledge, the communication by PivX regarding their forks has, in the past, not been very healthy. The important thing to do now is to clear up what the actual vulnerability is, and fix the problem to stop the exploitation. We’ve brought light to the problem and only want to see it resolved quickly and fairly.