Nano’s network suffered a DDoS attack on Saturday that involved delaying the confirmation of some transactions and an unsuccessful extortion attempt against the community and the Nano Foundation to stop the attack.
DDoS attack against Nano’s network
A few days ago, Nano’s network began to observe invalid blocks being sent to some main representatives (nodes that have at least 0.1% of the total delegated votes online) by a supposed anonymous node. These blocks, called unchecked, are not valid as they do not originate from the genesis account and have been labeled by the community as an attempt to overload the nodes – a kind of targeted denial of service (DDoS) attack – with the use of extra computational resources to check and clear blocks. It was not known for sure if the attacker’s intention was really this, or an unsuccessful double spend attempt, but because the attack consisted of sending a high volume of blocks easily identified as invalid, only to targeted nodes and not transmitted to the whole the network, leads to believe that the intention was really to overload the service and not to cause a fork. The nano protocol also automatically eliminates unchecked blocks in a few hours, so this excess of information was resolved in a short time, without affecting the network as a whole (although it harmed the node, which had to allocate bandwidth and CPU to deal with the overhead ). On April 21st, the creator of nano – Colin LeMahieu – made a post on the developer forum, explaining that due to the attacks that were being carried out against the nodes, the efforts of the development team would be in fixing the vulnerability exploited by the attacker.
Source: Nano Forum
“We are currently working on some changes related to the management of unverified blocks and other targets of this recent activity. While the impact so far has been minimal, working to mitigate future impacts is important and will take precedence over other updates.”
More robust spam attack on Saturday
On Saturday, April 23, two days after Colin’s publication regarding the attack, the network was finally affected by the efforts of the attacker, who carried out the same operation, but focusing on several main representatives at the same time, with a number of false blocks. really very high, which made some weaker nodes not resist and go offline. This made nano transactions take between 30 and even 60 minutes for some people. This delay in confirmations is very detrimental to the protocol, which is known to confirm transactions in less than a second. The duration for which users were affected was between 3 to 5 hours, which is the same time required for the protocol itself to eliminate non-valid blocks automatically. After the storage was cleaned up and the CPU overhead ended, the nodes were able to power up again and the network was back to normal. What ensured the success of this attack was the fact that more than 33% of all votes on the network went offline at the same time, causing the minimum amount of votes needed to reach consensus on transactions.
Source: NanoCrawler This is a defensive measure and an intentional design to avoid double spending. If this minimum amount of online votes did not exist, a similar attack could have the ability to control the majority of the consensus and make the “51% attack”, causing double spending, after taking down the weakest nodes.
How to prevent something like this from happening?
In a public, non-permissioned decentralized network like nano (XNO), anyone can become a node and get voting power – delegate or own – to become a main representative. In this way, even weaker computers can take a leading role on the network and be more easily hit by targeted attacks, as was the case this Saturday. When choosing a node as a representative, it is also important to take into account factors such as computing capacity and bandwidth. In nano’s ORV (Open Representative Voting) system, all addresses can change their representative at any time, with no time limitations and no need to lock funds through staking. Each address votes (or delegates) according to the account’s current online balance. In addition to the care of the entire community in delegating to stronger nodes, the developers are working on fixing the vulnerability that was exploited by the hacker, it is still unclear how this will be resolved, but the process can be followed in the GitHub repository: nano- node.
Blackmail against the Nano Foundation
So far, I have presented conclusive facts, but now we enter the area of speculation, theories and rumors, which I will share with you, the reader of Thegarret. A few weeks ago, the user DaRealJesus claimed responsibility for attacks on a community discord server.
He said that “still couldn’t do the spam attack”, when he was questioned by another member, but who was performing “optimization tests”, with the individual attacks. Which proved true on Saturday when the tests were put in place and managed to affect the network. Rumors in the groups say that DaRealJesus – a well-known and long-time member of the community, who has contributed a lot to the Nano ecosystem – lost over $5,000 from trading with XNO and felt a need for revenge. That’s why he was carrying out these attacks.
More rumors say that the “hacker” made an extortion attempt against the Nano Foundation, demanding payment of 10,000 XNO in order for him to stop the attacks.
The community, for the most part, was against paying the amount and it is a known fact that the Nano Foundation has no intention of doing so, having publicly ignored the attacker’s blackmail attempt.
More about this type of attack
Nodes keep getting a high amount of bad blocks, but so far no new delays have been recorded. An experienced developer – @trashman – said Saturday’s attack was robust and required a relevant framework to achieve the result achieved. He [trashman] tried to reproduce what was done and, even with 2 powerful computers and a good internet connection, it reached less than 10% of what was done by the attacker or, according to him, by the, more likely, group of attackers. Denial of service attacks, or spam attacks, are currently the biggest threats to the nano protocol, which has no fees to transact and is therefore more vulnerable to this. Delays, even if minimal, in transactions, hurt a lot business operations and users who use nano in their day-to-day lives, which is why the team is so committed to addressing these issues in future updates. Finding alternatives to charging fees that is effective against spam attacks, but ends up punishing honest users who have to pay the cost of prevention. Between March and May 2021, the nano network was the victim of a massive (and very expensive) spam attack that doubled the number of blocks on the ledger and caused delays of up to several days for some users, who had their money locked in blocks. unconfirmed. This attack was mitigated with the v22 software update that changed the way the network prioritizes the blocks to be confirmed, automatically punishing an alleged attacker and giving priority to legitimate users, through a queuing system that places transactions carried out by less used addresses. in front of addresses that are performing many transactions in sequence. Until now, other similar attacks had been carried out without success, demonstrating the efficiency of the method that it’s still far from ideal and continues to improve.
Read more:
NovaDAX is full of news! One of the largest cryptocurrency exchanges in Brazil has now ZERO withdrawal fees in real! NovaDAX also counts zero fees for Bitcoin transactions and more than 110 listed currencies, with cash withdrawal available and high liquidity. Cryptocurrencies with the best rates on the market! Simply activate the free Novawards program and enjoy reduced rates of up to 75%. Discover the NovaDAX Card and order yours now.
