Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 1745. (Read 9724017 times)

+1 that.

Yeah, I was just talking hypothetically. We don't need to do it at all, our current network scales to 1M+ and the Evolution scales to 200M+ out of the box. When we hit 50M or so, we can start debating. We'll be doing an Evolution v1 release, then v2, then v3. These scaling changes will be included in those later updates.

 No, because in essence a pro linux sys admin with semi-ninja skills can run 2 or more MN's from the same server.
 Though the point still stands for the majority at this point.

Are more MN neccesary? Maybe we could reduce 1000 to 500 if the price will be a problem to buy a MN or the network needs more MN to improve the network.
Reduce miners payment could be a good option 30/10/60 should be a incentive to increase the number of MN

Wasn't the 500 coin masternodes just an example of how the network could scale to even higher potential? Please, the Bitcoin block size debate has been bad enough and surely something like a change in the collateral needed for a masternode would be an issue for the voting mechanism.

Wasn't the 500 coin masternodes just an example of how the network could scale to even higher potential? Please, the Bitcoin block size debate has been bad enough and surely something like a change in the collateral needed for a masternode would be an issue for the voting mechanism.

And we should wait 12 days per payment... pay 2 vps... no @eduffield reduce to 500 dash it isnt the solution...

I mean per masternode.

I mean per masternode.

Collateral gets cut in half
The reward gets cut in half
Expenses remain the same
etc

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.

Wouldn't expenses double ? For a given holding, you've got to run twice the number of nodes for the same return.

Wouldn't expenses double ? For a given holding, you've got to run twice the number of nodes for the same return.

Wouldn't expenses double ? For a given holding, you've got to run twice the number of nodes for the same return.

What happens if we cut it in half?

The collateral gets halved
The reward gets halved
Expenses remain the same

For anyone interested in AdamWhite's real motivation for scam-trolling the Dash thread every day for the last 8 months, you can check his deleted posts from the Monero Speculation thread:

"im in this coin for the long haul. I've exchanged all my alts for XMR."

https://bitcointa.lk/threads/ann-mro-monero-a-coin-with-strong-privacy-based-on-cryptonote-technology.304375/page-509#post-7491079

Yup, it's a Monero Troll.

(A big one too, something like ~500 "Scam!" accusations posts on his competitor, i.e. Dash, threads, that's commitment.)

EDIT: If you look, he's deleted all posts relating to his Monero investments on BCT.  Guess he didn't know they are saved out there on the internets....

I'm not sure that works. But perhaps I'm missing something.

If you half the collateral, it doesn't follow that you double the masternodes.

First, the block reward hasn't changed, so the revenue to run nodes remains the same overall.

Second, going from one MN to two would potentially double the cost to run them - you have to ignore any speculation on price increases, although it would (speculating) potentially go up with real world adoption.

So, one server goes to two servers, but the reward remains the same.

If you introduce a micro fee, that would enable the network to scale with a reduction in collateral requirement.

But you have now two masternodes instead of one.