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.
It would be interesting to see the performance impact of running a higher transaction load. I'm all new to this so I might have it wrong (starting both nodes, btc, Dash, in August). I also run a bitcoin node and it is about 2x more network bandwidth (86 GiB for bitcoin for August vs 46 GiB dash), 15x more network connections (300+ for bitcoin vs 20 for Dash) and 4X more disk space (48 GB for bitcoin vs 14 GB for dash). It looks like when problems happen on the bitcoin network (different attacks) my CPU and memory shoot way up but otherwise it seems similar to Dash. While the rawmempoolinfo seems to be much higher on bitcoin (1000s vs singles in dash) I don't yet have a good enough understanding how that factors in to performance or if it matters.
If Dash started to get to the same usage as bitcoin I would guess that specs for many of the MNs would need to increase (not sure if Raspberry Pi which some MN are running could handle it). Would a VPS charge more? Increased transactions would probably lead to less decentralization as only those who could afford the costs could pay for it (that is if they are holding the MN remuneration for speculation). Similar to the problem that is seen in the decline of the current bitcoin nodes, though of course there isn't any compensation for running one.
