InstantXploit? Cool Name, No Threat
On the evening of July 11th, on the Dash Reddit, a user named u/needmoney90 posted what he considered an attack on the security of InstantSend (formerly known as InstantX). He hypothesized that using the payment queue as a guide and DDOSing other Masternodes, he could make it so six of his nodes would be in the quorum at the same time, allowing him to control the InstantSend transaction.
Here is the description of his attack:
- Take your 6000 Dash, and create 6 Master Nodes simultaneously. They will be placed sequentially into the back of the MN queue.
- Wait until your Masternodes are within 100 blocks of being in the top 10% of the queue, and then start calculating the nodes that will be in the top 10% once you reach it. You can do this by taking the previous 100 transactions, deterministically walking through the MNs that will be selected (and removed) at each step. Assuming no MNs drop out of the queue within the next 100 blocks, at this point you will know which nodes in the top 10% you will be competing against to validate an InstantX transaction.
- Over the next ~4 hours (100 blocks), selectively remove Masternodes from the network for 75 minutes at a time, using denial-of-service, cache poisoning, or some other method for bringing down a server. After 75 minutes, those competing MNs will conveniently lose their spot in the MN queue, allowing your 6 malicious nodes to all be chosen in the same quorum. At this point, you have degraded the security of an InstantX transaction (that your nodes are arbiters of) to the level of a 0-conf Bitcoin transaction, if not worse.
- Currently, the network is in a state of Sybil Attack. The Masternode selection criteria are designed to prevent any single person from controlling a majority of MNs in a quorum, but this is now not the case, due to the reliance on Stake for differentiating identity (as opposed to Work). Now that you’ve successfully performed a Sybil Attack on the MN network, you can perform the same attacks on merchants who accept InstantX transactions as you can perform on merchants who accept 0-conf Bitcoin transactions.
- An example attack would be to create two conflicting transactions, one of which sends N Dash to you (with a high fee, just in case), and the other sending the same N Dash to an InstantX-accepting merchant. Using your 6 Masternodes, sign both transactions as valid, and then locally broadcast the signed transaction sending coins to the merchant. The merchant will see a ‘valid transaction’ message (it was signed by the quorum of 6 MNs). After you have your ill-gotten goods, broadcast the doublespend transaction directly to a number of other nodes. With a little luck (it depends on which transactions are relayed to miners first), you will have successfully double-spent an InstantX transaction.
- Enjoy your free, ice-cold soda from the Dash vending machine, and try not to think about whether the $50,000 capital outlay and possible jail time (under the CFAA) were worth it.
Sounds scary. However, what this user did not know, and was made aware by TanteStefana, was that the Masternode quorum is not picked by the payment selection algorithm, but by the Proof of Work hash of a transaction involved in the InstantSend.
Dash developer moocowmoo added this post about the quorum selection process, which goes into further detail:
InstantSend (formerly InstantX) Transactions in Dash version 12 are secured using a consensus of deterministically selected masternodes.
This set of masternodes is informally termed quorum and must be in a majority agreement, at least six out of ten, for a successful lock of the transaction inputs.
Quorums are self-selected on a per-transaction basis using a combination of three elements: Transaction Height, Block Height, and Masternode Funding Transaction.
When an InstantSend transaction is broadcast, the height of the first unspent input in the transaction influences which proof of work hash to use as entropy for quorum selection. All InstantSend inputs must be at least six blocks old or the transaction will be rejected.
The height of the first InstantSend input isthen subtracted from the current blockchain height. This guarantees a new source of entropy every time a block is discovered. To prevent using transaction malleability to influence quorum selection, four is then added to the calculated block height to guarantee choosing a block generated after the input was created.
Masternode Funding Transaction
Each masternode receiving the InstantSend transaction lock request then compares the hash of its funding transaction to the hash of the block calculated above. After validating the inputs are not spent, the top ten masternodes closest to this proof of work hash broadcast their acceptance of the lock.
So, as you can see, Dash is interesting because it has elements of Proof of Stake with incentivised full nodes, but still very much relies on Proof of Work mining in its transactions. Its how Dash transactions can be decentralized, instantaneous, and secure.
We look forward to more attempts to break Dash technology.
Dash Reddit (InstantXsploit): https://m.reddit.com/r/dashpay/comments/4seua0/instantxploit/
Dash Atlassian: https://dashpay.atlassian.net/wiki/display/DOC/Quorum+Selection