Why don't we halve the Masternode collateral requirement now?

[raganius]

So... a MN with a larger deposit would get more voting rights and earn more? Interesting idea. It could end up reducing the number of MNs because people could put all their DASH in one node and enjoy the economic benefits of a larger payout while maintaining only one node.

Actually not: each Masternode, one vote... why change that?

 

[ec1warc1]

One more thought... looking at the blockchain as it is, it is vastly underused compared to the nodecount today. Sometimes we see a single transaction in a block, which means we need more every day users who just want a good service and don't care about how it works. It will happen soon enough.

 

[raganius]

One more thought... looking at the blockchain as it is, it is vastly underused compared to the nodecount today. Sometimes we see a single transaction in a block, which means we need more every day users who just want a good service and don't care about how it works. It will happen soon enough.

We maybe need more grassroot efforts spreading the knowledge about DASH, IMO. The community should give more value and support for those "evangelist members", I dare say...

 

[rustycase]

We maybe need more grassroot efforts spreading the knowledge about DASH, IMO. The community should give more value and support for those "evangelist members", I dare say...

This is very true !
Buy DASH, Use DASH !!!

Use it amongst your friends and offer DASH as a pay option in your business !

This sort of grassroots effort will always lead people to ask, What ? Why ? Will this be to MY advantage ?

A gud thing !
rc

 

[rustycase]

Historic rise of DASH to $15usd/share today on Poloniex will surely convince people DASH is a picture of value !
rc

 

[ashmoran]

I don't agree lowering (or raising) the Masternode collateral limits just to please the "poor guys" or the "rich guys" in the community, because that would make no sense at all.

This must be a technical decision: what is best for DASH performance.

I agree with the spirit of your point but I am not sure what you are implying by the details, so I would like to expand on something.

I agree entirely that making changes to Dash just to please one interest group or another would make no sense, it would be making changes without logic, and would set Dash adrift being pulled one way or another by each group. What I think needs clarifying is the scope of "technical decision" and "DASH performance". It is easy to read these terms and think of only decisions that directly relate to code, and only performance that can be measured by hard metrics. I would like to expand first the scope of "technical" to include everything that can be managed scientifically, even if it is hard to measure directly. So this would include management, marketing, purchasing (eg paying for an ATM integration through the budget system); second the scope of "performance" to everything relevant to using Dash, so how quickly a shop customer can buy their coffee with Evolution, as well as how many InstandSend transactions per second a masternode can validate. (I only just wrote a comment on Reddit where I use the same ideas.) It is much harder to measure the effect of an social media promotion on Dash usage than it is to measure the effect of a code change on block verification time, but here are still technical decisions (eg "don't be rude") that affect performance (eg "percentage of people who read tweets who then visit dash.org"), even though they may be harder to define and measure.

You may have thought about some or all of these already – I just try to expand the scope of "technical", "performance" and so on to cover as much of a system as possible, otherwise there's a risk of focussing too much on one part and forgetting about another. Everything works together to create Dash, and changing one thing affects everything else indirectly, so it helps to keep a wide field of view.

But, a possible solution would be that of the spreadcoin guys: no fixed limit for the collateral, but else, a fixed optimal number of Masternodes....

...Say the developers calculate that the network needs 5k Masternodes in order to operate perfectly in the current context. So the network will only recognise 5 thousand Masternodes, and there will be a set of minimal requirements for a Masternode to be accepted, like reliance, speed, responsiveness, ping and whatever is important according to the technical point of view.

This sort of line of thinking is promising I think. The 1000 DASH is just an arbitrary figures should that has proved a good starting point, but the number of masternodes would be best determined by fitting into some broader goal for Dash. How, exactly, I don't know – but I think it's worthy of further thought and research.

 

[raganius]

Actually I have got no technical knowledge to assess what would be the parameters there. But one thing seem to make sense to me: DASH does not need too many nor to few Masternodes, so (I guess) there might be an ideal number of nodes for the network to run smothly in a specific reality/context (too many Masternodes and the network is clogged, to few, and it is stuck). and it also makes sense to me that this "ideal number" of Masternodes may vary with time/network size (?).

Anyway, I am not the best person to give the final solution here.

 

[freshdopamine]

Anyone serious about changes on how many DASH you need to run a masternode should put a proposal.

When Evolution hits our network some people will need to upgrade their hardware. But it wouldn't make sense to lower the DASH required due to less ROI for the people running a masternode.