[...]Masternodes could indeed wreck havoc. The InstantX white paper shows some math that claims an adversary needs 2/3 of the masternodes to attain 1.72% chance of controlling the majority of a single quorum. I think this math may be flawed. Can you whip up the correct probability math quickly or should I?
https://www.dash.org/instantx/I see the flaw in Dash's math:
Probabilities of attack can be calculated by the chance of a masternode being selected as the winning node for a given block (1/1000). To subvert the system an attacker would require operating all ten masternodes that won a given election
The attacker only needs less than 10 of the of masternodes which are eligible to authorize an InstantX lock for a specific UTXO. Because if InstantX requires all 10 masternodes to authorize (which I believe is what the white paper implies), then the attacker can block (i.e. jam) InstantX 65% of the time with only 1/10 of the masternodes! With 50% of the masternodes, the attacker could jam the InstantX 99.9% of the time. There is the 50% attack. This is probably why for Evolution, Evan changed the requirement to a simple majority (or some N-of-M) of each eligible quorum.
Dash's flawed math in the InstantX paper incorrectly assumes the attacker needs all 10 of the eligible masternodes.
Thus if the attacker owns 50% of the masternodes, the attacker has at least the 6/10th majority in 38% of the InstantX transactions and also can block (jam) the InstantX transactions 62% time with only at least a 5/10ths minority. Thus the attacker can attack 38 + 62 = 100% of the time. There is the 50% attack again. And Evan erroneously claimed that Evolution eliminates the 50% attack.

That is the hypergeometric distribution.
https://en.wikipedia.org/wiki/Hypergeometric_distributionhttp://math.stackexchange.com/questions/422414/probability-of-selecting-q-red-balls-from-m-red-balls-and-n-blue-ballsSo enter here:
http://stattrek.com/online-calculator/hypergeometric.aspx | 1000 masternodes |
Number of successes in population: | 500 adversarial, colluding masternodes |
| 10 eligible masternodes |
Number of successes in sample (x): | 6 needed for a majority |
I don't think anyone has the incentive to buy up 50% of the masternodes to do the other attacks (actually the attacks could be achieved somewhat infrequently with a much smaller % of the masternodes, e.g. with 10% of the masternodes every 666th UTXO could be jammed and every 10,000th UTXO could be spent as many times as desired).
IX requires 6 of 10 signatures to create a transaction lock. This entire argument is based on an invalid premise! So your jamming attack doesn't work...
https://github.com/evan82/dash/blob/master/src/instantx.h#L25The paper is very outdated and this is why I should have written the code first, then the whitepaper second. I found all of these issues when I was actually writing the code, so it doesn't include any of them.
https://github.com/evan82/dash/blob/master/src/instantx.cpphttps://github.com/evan82/dash/blob/master/src/instantx.hhttps://github.com/evan82/dash/blob/master/src/main.cpp#L2973You should really try to follow the progress of evolution, what's happening is getting exciting. All of the existing Dash technology is just a simple prototype of what we're now making.
For example, the new quorum system uses age-based quorum layering. Each quorum will have 25% nodes that are very old (more than 2 years), 25% that are more than a year, 25% that are more than six months and 25% that are more recent. As the network gets older, we will also use the most trusted nodes as 25% of all quorums, so it becomes impossible to gain a majority as a bad actor.
Also, you said this "Thus if the attacker owns 50% of the masternodes, the attacker has at least the 6/10th majority in 38% of the InstantX transactions and also can block (jam) the InstantX transactions 62% time with only at least a 5/10ths minority. Thus the attacker can attack 38 + 62 = 100% of the time. There is the 50% attack again. And Evan erroneously claimed that Evolution eliminates the 50% attack.

"
That's not a 51% attack! There's only one and it's related to mining... That's the one I'm trying to solve. The idea behind this is I can create a system where the masternodes via quorum actions will determine which blocks will have which transactions... If the miners don't decide which transactions are in which block, it removes all mining vulnerabilities. They are responsible for creating the proof of work hashes, which are the bases for the quorum selection.
Feedback and discussion is always welcome! Thanks for helping us make Dash Evolution better.
