Privacy-oriented payments focused cryptocurrency Dash underwent a ‘sought-of’ attack following a flurry of small transactions totaling almost 1 million 1 input/1 output transactions with a fee just higher than 1 duff per byte. The transactions were unanticipated which led most in the community to suspect an attack but no one knows for sure. According to the Dash Core developers, it could either be an attempted attack or a developer outside the Dash Community who was conducting a stress test. Either way, it wreaked havoc to the network with several legitimate transactions going unconfirmed for several hours.
Following this attack, the Dash Core Group conducted an impromptu investigation to understand the nature of the ‘attack’ and has released a series of discoveries. On Friday, the DCG released a patch for the Dash software to help address the vulnerabilities that could have allowed the attacker to cause the network hog. Here are some of the things that DCG discovered about its network:
- Some pools are capped at 1MB blocks – several mining pools on the Dash network had implemented 1MB transaction size limits which led to the freeze following the flurry of transactions that the network experienced on the 7th.
- Some pools seem not to be emptying the mempool and are producing near-empty blocks – mining pools seemed to prioritize the low size and low transactions that were being conducted by the ‘attacker’ while several of the legitimate transactions were getting stuck in the mempool.
- Some Masternodes crashed due to not having enough storage space – due to the significant transaction surge, several master nodes hit their storage space limits of about 15-20 GBs as they had to save the InstantSend (IS) Locks for every transaction. This led to some of them crashing due to maxing out space limits.
- Some Masternodes banned other Masternodes under high load when on the brink of a new quorum becoming active – similar to the previous point, as some master nodes crashed few that did not have space limits were left to function under increased stress that led to node burnouts. As explained by the DCG “this issue resulted in some blocks not receiving a ChainLock and some transactions not receiving IS Locks.”
- Some user transactions did not get included in a block rapidly since they used the default fee – users of the default Dash Core Wallet had their transactions during the ‘attack’ stuck in the mempool as the transactions were being sent without adjustment to the network traffic requirements.
The new update, released on Friday by the DCG will help address most of these concerns and here’s a run-down of the fixes present in the Dash Core v.0.14.0.3.
- Database space usage improvements
- DKG and LLMQ signing failures fixed
- Signed binaries for Windows
- MacOS: disable AppNap during sync and mixing
- New RPC command: quorum memberof <proTxHash>
- More information about the number of InstantSend locks
No losses were reported after the attack was addressed last week but the core developers had a rude awakening work on the network to ensure that such an attack does not repeat in the future. Depending on how you look at it, this could have been a white hacker forcing the DCG to innovate and build a more secure network or a botched attempt at causing havoc. Either way, the network is more secure now than it was before the attack but there is still room for improvements.
