Breaking Verge: how it was (part of 2)

The first part

Time warping, mining vulnerabilities, DOS attacks, and more.

Mining in Verge: when the 5 algorithms are brute force

Traditionally, in cryptocurrencies based on the proof-of-work protocol, blocks are mined using a single algorithm, most often SHA-256. In Verge, you could use 5 different algorithms (for the curious - Scrypt, X17, Lyra2rev2, myr-groestl and blake2s.). The reason for using multiple algorithms is described below.

Some Bitcoin critics argue that over time Bitcoin mining has become too specialized and centralized, most of the mining is done on ASICs (short for application-specific integrated circuit) - devices designed exclusively for currency mining, and most of Bitcoin mining is done in multiple mining pools by groups of miners who pool their resources and share what they earn among themselves. These tendencies towards different types of "centralization", they say, contradict the fundamental principle of cryptocurrencies. Using a coin with multiple mining algorithms counterbalances such trends. The rationale is that managing five different algorithms in terms of hardware, production and resource management will inevitably be more difficult than controlling one algorithm, allowing Verge to achieve greater decentralization and distribution of mining.

The situation is this: the only way to achieve correct operation - and the concept of “correct operation” in this case includes maintaining the 30-second interval between the blocks, maintaining the economic viability of all five algorithms for miners and preventing the dominance of one algorithm (which would deprive the whole experiment) - to make it so that each algorithm has its own complexity parameter, which would be configured independently of the other four. In other words, the complexity of mining in the Scrypt algorithm is configured to comply with the 30-second interval for each block, as in X17 and other algorithms.

This means that our hacker did not really reduce the complexity of mining for the entire network; he lowered it only for those who mine using one of the five algorithms - Scrypt. And while the miners of Scrypt enjoyed a ridiculously easy mining, for the other miners working on other algorithms, the complexity of the tasks did not decrease, which means that their total power would not help ensure the security of the network. This meant that the attacker worked only with the Scrypt algorithm and had to compete with other users who did the same; Thus, the required hash power for our attacker was no more than 50% (dominance over the entire network), but only more than 10% (dominance over other miners of Scrypt).

We will now go into the realm of speculation, but it looks like the situation was even worse. We assumed a figure of 10%, based on the fact that approximately the same amount of resources should be allocated for each algorithm (this is the essence of the mining difficulty setting mechanism). In reality, however, the axioms of a free market economy are not always observed. It is believed in the community that various factors - for example, the existence of unactivated ASICs for Scrypt, as well as free resources available for rent through Nicehash, etc. - led to the fact that the dominance of mining on Scrypt during the attack was much cheaper. than any other of the four algorithms. It is safe to assume that the required hash rate ended up being much less than 10% - according to some preliminary estimates given on Reddit, the hash rate could be as low as 0,4%.

To summarize: the fake time stamps made it possible to drastically reduce the complexity of mining; the use of five algorithms meant that it was possible to reduce the complexity of only one of them, which greatly simplified the capture of the entire network; the economic and production status of this particular mining algorithm has further simplified capture; and finally, due to the reduced complexity of mining, the time for the formation of blocks has been drastically reduced, making the attack approximately 30 times more profitable.

Lessons learned

What conclusion can be drawn from this situation? The short-term effects of hacking were predictably chaotic and incomprehensible. A few days later, the main developers corrected several errors with the help of utilities, in which errors could also creep in, and ultimately they had a hard fork in the network, which could have happened initially by chance (well, or not by accident). As for the reaction in the world, during the week after the hacking Verge price increased by 30%, and the next week it was announced that the currency Verge will be accepted as a payment for a subscription to pornhub.com. As the largest protocol-level cryptocurrency could lead to an increase in the price of this currency and, later, to conclude a partnership with the most visited porn site - I will leave this question open. Personally, I think that the point is simply that there is no point in the world, and people are completely crazy.

But I digress. Thinking more globally, we can learn a few lessons from this situation:

First, the technique of using timestamps to artificially reduce complexity has actually been known for a long time, and even managed to get the name - the "time-warp" vulnerability. Several years ago, an attack vector was discussed on the Bitcoin forum. To some extent, the use of the newer difficulty adjustment algorithm Dark Gravity Well, in which the difficulty is adjusted with each new block, helped to implement the attack on Verge. In Bitcoin, the difficulty only changes every 2016 blocks. Despite the fact that such a time-consuming and intermittent difficulty setting may seem like a strange decision, the Verge hack made it clear that it is in fact a security measure: if there is some way in Bitcoin to reduce the complexity of mining, then an attacker can do it. only once every 2 weeks, which makes the attack results negligible compared to Verge, where hackers can lower the mining difficulty every 30 seconds.

Interestingly, one of the purported advantages of Dark Gravity Wave is that it has to be immune to a time-warp vulnerability. Given how strongly this assumption has been disproved, other currencies using this algorithm should at least get nervous.

Regarding the use of five algorithms: although at first glance this seems to be a worthy experiment in an economically stimulating decentralized environment, it introduces new challenges that inevitably increase the likelihood of unforeseen vulnerabilities.

In both cases, this hacking represents a strong argument in favor of proven mechanisms, and calls for caution with the complication and introduction of unjustified risks associated with people's financial assets. In these matters, the Bitcoin team showed its best.

The issue is somewhat broader: software developers, although they are reluctant to admit it, are ultimately just people. Even when the basic principles of security seem completely reliable, there can always be a place for a mistake. There are unexpected attacks, compromises do not always justify themselves and, of course, no one has canceled the possibility of the emergence of good old bugs. The software does not always work the way we want, and no one in 2018 was surprised that such bugs could lead to loss of funds. But when the software itself is With money, we need to be especially careful.

Given that most of us do not have free time to conduct a thorough analysis of the code of each project in which we invest, the best protection against a catastrophe is trust in proven systems with positive experience and a conservative approach to development.

And if you want to bet on some funds in pilot projects related to the transfer of money, then you should at least be aware of the risks. Ultimately, the best defense is when the community demands that appropriate measures be taken to prevent future disasters. If I am not mistaken, then George Santayana said: "Those who cannot learn from the vulnerabilities in the security systems of the past are doomed to repeat them again and again in the future." These words need to be remembered so that we unexpectedly again will not repeat the mistakes of the past.

Rate this article
Blockchain media