This post is also available in: Deutsch
Pasta, a Dash Core developer, explained the subsequent investigation to discover the cause of the transactions.
“Last week there was an abnormally high network load on the Dash network consisting of around a million 1 input 1 output transactions with a fee just higher than 1 duff per byte. After contacting all likely community members who could have executed this and finding that none of them were involved, it appears that the artificial load on the Dash network was either a stress test by someone outside of the Dash developer community or was an attempted attack.”
The investigation also lead to various discoveries that Dash Core Group will address directly or through the 0.14.0.3 release to improve the network to “to ensure that users can send funds at a sub cent fee while also preventing spam and attacks on the Dash network”. One of the major network improvements relates to fixing InstantSend locks since masternodes were crashing due to not having enough storage.
“This was a result of having to store the IS Lock for every transaction. This resulted in nodes running on minimal storage (around 15–20 GB) not having enough space to store all of the IS Locks. Previously, locks were removed after around 7 days. After 0.14.0.3 (PR#3048), IS Locks will be removed as soon as they are confirmed via a ChainLock. This should reduce the size of the `llmq` directory significantly over time.”
A fix to an unforeseen problem with default InstantSend
Some of the problems revealed by the flurry of transactions are relatively confined problems to fix that simply depend on finding coding solutions to problems such as the InstentSend Lock fix above. These also include updating the fee selection algorithm and UI in the Dash Core Wallet “in 0.14.1 thanks to the backporting of Bitcoin 0.15” along with reevaluating the fee selection algorithm in mobile wallets. Additionally, “[s]ome Masternodes bann[ing] other Masternodes under high load when on the brink of a new quorum becoming active”.
“In order to fix this, we need to detect this situation and then re-verify failed sigs with the previous active set. This is being implemented by PR#3052 and will also be released in 0.14.0.3. This issue resulted in some blocks not receiving a ChainLock and some transactions not receiving IS Locks.”
However, some other fixes require more soft operations from Dash Core team members by reaching out to third parties. This includes “[s]ome pools [being] capped at 1MB blocks”, which the post says is “likely due to custom implementations”. The post also went on to say that “[m]ining pools will change this naturally once usage approaches 1MB in an effort to capture more fees and be more profitable”. Additionally, Pasta described that “[s]ome pools seem not to be emptying the mempool and are producing near empty blocks”, which they are actively trying to solve.
“We are in active communication with these pools in order to figure out what we can do such that the pools include transactions while not including what appears to be spam (1 input, 1 output, very low fee).”
Fine-tuning network performance to support mass-market use
The initially unknown spike in transactions and subsequent investigation might have been unplanned at first, but the effects of evaluating the network and implementing changes highlights strengths of Dash. While some coins, like Litecoin struggle to maintain an active development community, Dash is able to maintain a thriving development group funded by the DAO Treasury. This has been able to keep Dash in an active development state, which helps ensure that Dash maintains its ability to be inexpensive, quick, and also decentralized so it can be used in everyday transactions as digital cash.