Quick and possibly daft question on the method for selecting the 10 masternodes. The 10 nodes to handle a transaction are selected by the 10 nearest transaction IDs for the 1000 Dash transaction needed to set up the masternode (I think). Is that vulnerable to the malleability issues Bitcoin is seeing at the mo? ie. could transaction IDs be modified to direct to a small number of malicious masternodes?
Unless I'm mistaken, it's based off the block hash, not the transaction IDs.
All security is inherited from the mining network, which basically is deterministically setting up the quorum system, in a way that is provable. For example when you use DAPI, it will do something like create a transaction from Xaddr1 to Xaddr2 for 10 DASH. You then get back your command, a result status and all of the signatures from the quorum participants. You as the end user will know what quorum is activated for that node already, so you can tell if they're lying.
In terms of scalability, if we have 3300 masternodes and a quorum size of 10, that means we can handle 330 requests at once. If the average time per request is about 100 ms, that means we can do 3300 requests per second. The estimate is based on the fact that the network is also doing maintenance at all times (propagating blocks, shard updates, syncing clients, etc), so I'm guessing ~50% of a fully utilized network will go to other activities. Therefore we end up with 1650 requests per second.
Also we're going to aim for your average every day user, so we're talking just a few requests per month. So how many users can we support if they use 15 requests per month? 86400*1650*30/15 = 285,120,000. Ok, 285 million, that's pretty good.
What about reducing the collateral to 500 DASH? Now we have 6600 masternodes and can handle 570 million users. Isn't the masternode count going up anyway? Yep. That number should hit about 700M about when we launch. This is why it says 500-1500 tx per second, I guess that should say "requests per second" because it's not really accurate. Also the 700M should be a range also, that's the high end, the low end is 285M for current Dash requirements.
I've done a lot of guesswork to figure out these numbers, we'll see how close I am when we start seeing some serious adoption. Either way the system is built to scale with adoption in a way nothing else can, it should be pretty cool. I figure if we start to see a good deal of adoption and usage, we'll always either ask for more storage, processing power or reduce the collateral to split the network before it becomes an issue . They'll be good problems to have and we'll have lots of solutions available.