Intense Coin experienced an attack to its blockchain on April 15, 2018. In this post we will describe the attack, the implications and our plan for resolution.
The most important portion of this post is the fact that the Intense Coin blockchain will be hard forking and rolling back to block 166,133 in the next several days. This means that anything happening on the blockchain between now and the hardfork is meaningless, as the activity will end up on a chain that is not supported by most of the network.
We will do whatever it takes to keep our network operating to fulfill our ultimate goal, which is providing blockchain backed decentralized VPN and unrestricted access to the internet.
What happened (simple)?
An attacker was able to achieve the majority of hashrate on the Intense Coin network and thus be responsible for all or most of the blocks being added to the chain. This is commonly described as a “51% attack”. As the attacker controlled the majority of the hashrate, they stopped allowing transactions to be included in new blocks. Most significantly, the attacker manipulated timestamps of the blocks to exploit a weakness in the difficulty calculation algorithm of the coin. This manipulation allowed the attacker to find about 8 days worth of blocks in several hours.
For more nitty-gritty technical details, jump to the in-depth explanation at the end.
What is the response?
As almost 6,000 blocks were stolen by the attacker(s), the blockchain will be rolled back to the last normal block before the attack started. The last normal block was block 166,133. The Intense Coin blockchain will hardfork to version 4 in the next several days as the developers conduct testing. Version 4 will include several new features:
- Adoption of zawy12’s LWMA difficulty algorithm, which is much more responsive to hash power fluctuations. LWMA has been live on several coin networks for a few months. Zawy and the coin developers have worked out the bugs, and the algorithm has proven to be very reliable in testing and production.
- Reducing the future time limit on blocks to 500 seconds, down from 7,200 seconds.
- Adopting Monero’s RingCT transactions to maximize privacy.
- Adopting the CryptoNight variant 1 proof-of-work change to combat ASICs.
- Requiring 4 mixins per transaction.
This hard fork was originally planned for May 14, 2018, but the circumstances of this emergency situation have required the date to be advanced. We are estimating a new hard fork date of April 21, 2018. The Intense Coin developers are working as much as possible to deliver earlier on that date, but we are confident we can meet that deadline without exception. The implications of hard forking are significant and our team would rather spend a couple extra days making sure the kinks are worked out than force another hard fork in short order. You can follow our progress or make contributions in the various block_v4 branches on GitHub.
As the blockchain is rolling back, anything that happens on the chain between now and the hard fork is meaningless. Users are advised to direct hash power elsewhere until the hard fork. Do not purchase any ITNS in exchange for other assets. ITNS that is already deposited to exchanges can be safely traded on exchanges, as the trading is not actually using network transactions. To learn more about what the hard fork means for you, please read our forthcoming article (coming soon). In short, you will need to upgrade to the latest software.
Why wasn’t this press release available yesterday?
We regret that we were not able to inform you of the precise details and implications of the situation upon learning about it yesterday. We were alerted to the suspicious blockchain activity within an hour of it occurring. We immediately began analysis and planning to solve the problem.
Before we could release this statement, we had to contact exchanges and ensure they suspended deposits and withdrawals to limit the exposure of this attack. This was vitally important to ensure that exchanges were not left “holding the bag” as their ITNS vanished during the rollback and hard fork. On a sunday evening, some exchanges were unreachable. This morning, we received confirmation that deposits and withdrawals were halted, and had been since yesterday for most exchanges. This post was published 24 hours after the attack started.
Related attacks and conclusion
This is the third time in four weeks that the Intense Coin blockchain and network have been attacked. In March, repeated attempts were made to insert arbitrary data into the blockchain, which broke sync abilities for rebase clients (see Issue 45). Fortunately, through persistence by attackers, the Intense Coin developers have been given the opportunity to sharpen their exploit response swords! During the first attacks in March, it took our developers a day or two to get a handle on things. Now, during the timestamp attack, our developers had remedial code in testing less than 12 hours after the attack occurred.
The Intense Coin network and team are only becoming hardened and stronger by these attacks. Our developers are working to mitigate new potential attack vectors and they are operating with a much stronger sense of security preservation. We will do whatever it takes to keep our network operating to fulfill our ultimate goal, which is providing blockchain backed decentralized VPN and unrestricted access to the internet. We are not inviting attackers but rather letting them know that if push comes to shove, we will fight!
Thank you for your patience as we work to resolve the issue. If you have any thoughts or comments, please join us on Discord and let someone from the @Intense Team know, or me personally at @valiant#3443.
Continued: What happened (in-depth)?
Intense Coin adopted the Sumokoin “v5.5” difficulty algorithm on November 26, 2017 at block 71,000. The Sumokoin difficulty algorithm offered significant improvement in adjustment speed compared the standard CryptoNote difficulty algorithm, due to the fact that the legacy algorithm did not respond well to large fluctuations in hash power on relatively small coin networks. The classic CryptoNote difficulty algorithm uses a 600 block window for difficulty adjustments, compared to Sumokoin’s block window of 17. At that time, Sumokoin’s v5.5 difficulty algorithm had been in effect on their live network for 5 months, and was extensively audited and collaborated upon by multiple coders. For these reasons, the Intense blockchain developers placed good faith in Sumokoin’s difficulty algorithm.
On April 15, the Sumokoin v5.5 difficulty algorithm was exploited by manipulation of timestamps. The algorithm examines the median of the past 17 blocks to determine difficulty. As timestamps were advanced several minutes or hours for 1 block, then rewound to “normal” for 2-3 successive blocks, the algorithm saw an overall large median solve time which reduced difficulty. As the timestamps were then sorted, the two regular blocks became canceled out by the one massively negative block, leading to a progressively dropping difficulty. This process was repeated several thousand times, allowing the attacker to solve blocks in a very short amount of time and collect a tremendous number of Intense Coins. The attack began at block 166,134 and continued until around block 171,900.
The vulnerability in the median solving time was exacerbated by a poor design decision in CryptoNote-based coins. The design flaw is an excessively long future time limit. The future time limit describes how far in advance a node will accept a new block as being solved compared to his local time. CryptoNote permits this value to be 7,200 seconds, or 2 hours, out of the box. Many CryptoNote-based coins, including Monero and Intense Coin, still use the default of 7,200 seconds. Combining the weakness in the future time limit with a difficulty algorithm that calculates based upon median solve time allowed the attackers to have a sizeable impact on the blockchain.
Addendum: I’m updating this post to add some clarity regarding Sumokoin, as the Sumo developers felt we were implying weakness in their algorithm. The Sumokoin native implementation would not be exploitable in the same fashion that the Intense Coin implementation was. When Intense Coin developers adopted the Sumokoin algorithm, they neglected to notice that Sumokoin had shortened the default 7,200 future time limit. The future time limit variable, and another variable responsible for evaluating timestamps, were renamed in Sumo’s code and missed in the initial review and adoption.