• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Should Platform run on all nodes or should Platform run only on High Performance nodes ?

@qwizzie I do not understand why a 1k solution would be better. It has the worst security of any system, the second highest fees, so very bad returns.

Why do believe this is a compromise scenario? Normal masternode owners would be much worse off, plus our system would run with half the performance.
 
We also have an ongoing miner-masternode reward-allocation shift going on untill 2025, could impact yearly return (or not)
See : https://www.dash.org/forum/threads/updated-mn-miner-reallocation-schedule.51453/

With regards to worst security of any system : they are all under 0.2% so what are we even talking about here with these very very low percentages ?

Storage Fees are cut in half in comparison with running Platform on all nodes (which was the most likely option for masternode owners against sacrificing decentralisation for lower fees, before the 1k masternode solution emerged). That is the compromise part for devs. Much lower storage fees for DCG worst case scenerio (with network not approving the DCG HPM decision proposals).

I can accept these storage fees and calculated ROI, when that means Dash stays decentralized and every masternode owner has the option to support Platform (and receive Platform rewards).

We have no way of knowing how Dash Platform adoptation will work out after launch. If we ever max out on our performance, due to overwhelming Platform adoptation then perhaps we can think of upgrading the hardware requirements a level higher ? Or start working on sharding ?

I also don't rule out fine-tuning and optimizing Dash Platform could bring those Storage fees a fair bit down over the years after launch.
Look at what you achieved already through optimization and looking at code again ? I think those storage fees were orginally a lot higher.
I bet a lot more eyes will be looking at this after launch.
 
Last edited:
0.13% per quorum, 24 quorums in a day, 356 days in a year (8544 tries).

1k Solution: P = (1 - (1 - 0.0013)^8544) = 99.99%

4k Solution: P = (1 - (1 - 0.0003)^8544) = 92.30%

10k Solution: P = (1 - (1 - 0.0000001)^8544) = 0.08% (best)

Now this is assuming you take the largest whale and add 40% to what they own.

Let's do the same calculation with 20% more than they currently have

1k Solution: P = (1 - (1 - 0.0013)^8544) = 38.66%

4k Solution: P = (1 - (1 - 0.0003)^8544) = 5.84%

10k Solution: 0 (best, +20% can never give them ability to stop network)

What we would most likely do though is rotate less often to increase the security of the 4k system, in the 1 k system there are so many nodes, that not rotating frequently could mean that some nodes get no platform rewards in an epoch as it is probabilistic to decide who is in a quorum.
 
0.13% per quorum, 24 quorums in a day, 356 days in a year (8544 tries).

1k Solution: P = (1 - (1 - 0.0013)^8544) = 99.99%

4k Solution: P = (1 - (1 - 0.0003)^8544) = 92.30%

10k Solution: P = (1 - (1 - 0.0000001)^8544) = 0.08% (best)

Now this is assuming you take the largest whale and add 40% to what they own.

Let's do the same calculation with 20% more than they currently have

1k Solution: P = (1 - (1 - 0.0013)^8544) = 38.66%

4k Solution: P = (1 - (1 - 0.0003)^8544) = 5.84%

10k Solution: 0 (best, +20% can never give them ability to stop network)

What we would most likely do though is rotate less often to increase the security of the 4k system, in the 1 k system there are so many nodes, that not rotating frequently could mean that some nodes get no platform rewards in an epoch as it is probabilistic to decide who is in a quorum.

What is the above for Platform on all nodes ?
P = (1 - (1 - 0.0006)^8544) i assume ? I tried to calculate, not sure i got the numbers right ( particularly not sure for the calculation with 20% more then they currently have). I got to 99.41 % so far (even that could be totally wrong)

And what is the above calculations from our current masternode quorums, running through our current masternodes ?
I am curious to those percentages as well, just to see what the current chance to stop a quorum right now is with current number of quorums, 356 days in a year

The whole thing is of course a lot of assumptions with regards to Dash whales possession and them that easily adding 20% or 40% to what they own and having whales attack Dash 356 days in a year (which seems a bit weird to take into account).
 
Last edited:
(1 - (1 - 0.0006)^8544) =99.41%

The whole point of v18 was to make instant send extremely extremely secure against double signs. That quorum has a lot of security features (rotating only a portion) that wouldn't benefit platform. It's really comparing apples to oranges, but I think we did the calculation and we are very close to 0.

The chance that the top MNO could double sign a Chain Lock is relatively high if he is able to attack the network with a timing attack, which is very very hard to pull off. In the case that they do pull this off, chain locks would just stop working and we would revert to pure PoW (basically they would gain absolutely nothing as the chain would continue). I guess at that point they could attempt a 51% hash based attack, but it's still a lot of ifs. We are going to improve the security of chain locks in v20.
 
So the only security weakness for the Platform on all nodes solution, 1K masternode solution and the 4K HPM solution would be timing attacks from large Dash whales ? (very very difficult to pull off). And security against that is getting beefed up through future v20

Only 10K HPM solution would have protection against this / very low chance of this happening, from the very start
Can this not be integrated into v19 ?
 
Last edited:
No @qwizzie, timing attacks are just for chain locks.

Ok, so if below calculations are for Platform and calculates the ability to stop the network and assumes we take the largest whale and add 40% to what they own
and ultimately come up with these numbers :

Platform on all nodes : P = (1 - (1 - 0.0006)^8544) =99.41%

1k Solution: P = (1 - (1 - 0.0013)^8544) = 99.99%

4k Solution: P = (1 - (1 - 0.0003)^8544) = 92.30%

10k Solution: P = (1 - (1 - 0.0000001)^8544) = 0.08% (best)

then that means something went really terribly wrong during Platform development over the many many years with regards to Platform security and we are now at a point, where only severe 10K centralization is the way forward. All other solutions (even the 4K HPM solution) are all extremely bad.

That is hard to believe. That would mean devs have really screwed up and should all be fired on the spot (my over the top reaction on an over the top situation)

Rotating less to increase security for 4K HPM's, while not being able to do the same for 1K masternodes or for Platform on all nodes (due to Platform Credits not being distributed deterministicly), is on itself a pretty bad design flaw of the probabilistic nature of the Platform Credits. In a way Dash Platform is in that regard one step forward and two steps back.

Anyways i think all these assumptions about Dash whales, attacking Platform 356 days in a year (8544 tries) with 40% more then what they own
is not all that realistic. It is nice to use as example to highlight a specific solution, but out in the real world this seems highly unlikely.


Maybe we should make percentages on above percentage numbers, to determine the odds of those percentage numbers coming true.
 
Last edited:
All I am reading are just attempts to win the argument from QuantumExplorer, which I fully understand has performance/hardware geek myself. Which is okay if Dash was just a hobby project, but its not. It actually blocks the thought process of how to get as decentralized as possible, and move to how to make Dash the fastest. It is perhaps just a blindspot, or at worst childest unprofesional behavior, just like me overclocking, undervolting, killing all none required software, just to get that extra low Watt usage or higher fps, during benchmarking.

For example the argument that masternodes are running less than optimal server is not one and the same question.
that is actually about more and stricter PoSe requirements, the options to test if the hardware and network connections are optiomal actually increase with dashplatform.

"just an example"
You could for example give all Dashplatform nodes the option to querry idle other masternodes, if they don't act fast enough, the get there first PoSe points, than just hammering them till they get a PoSe ban, the optimal masternodes will not suffer because the can handle the let say 50 querry request per second. Obviously, the test would require, 3 party's one the dashplatform node, 2 the challanger(the one claiming that a specific node is running below required specs), and 3 observer that both party's are playing fair.
 
0.13% per quorum, 24 quorums in a day, 356 days in a year (8544 tries).

1k Solution: P = (1 - (1 - 0.0013)^8544) = 99.99%

4k Solution: P = (1 - (1 - 0.0003)^8544) = 92.30%

10k Solution: P = (1 - (1 - 0.0000001)^8544) = 0.08% (best)

Now this is assuming you take the largest whale and add 40% to what they own.

Let's do the same calculation with 20% more than they currently have

1k Solution: P = (1 - (1 - 0.0013)^8544) = 38.66%

4k Solution: P = (1 - (1 - 0.0003)^8544) = 5.84%

10k Solution: 0 (best, +20% can never give them ability to stop network)

What we would most likely do though is rotate less often to increase the security of the 4k system, in the 1 k system there are so many nodes, that not rotating frequently could mean that some nodes get no platform rewards in an epoch as it is probabilistic to decide who is in a quorum.

Wait! How many days are there in a year? ;))
 
You could for example give all Dashplatform nodes the option to querry idle other masternodes,

And that is one of the big failures of Platform, Sam has admitted there is no robust Proof of Service for Platform! There exist several protocols for measuring network performance and proof of storage.

Instead, what I've read is, "the code for HPMNs is just a few lines, in fact it''s already been done".

It's a timely process explaining to people that 3673 paid masternodes are better than bitcoin's 15224 unpaid nodes. And now we're expected to be financially rewarded for an even smaller elite network?

All this FUD about performance and usage costs. How about the OG's that put up with DCGs shit for seven or eight years? Where is your pricing and security estimates for 100 Dash Masternodes and 1000 Dash HPMNs? What's up with that, too much code to write?

Perhaps, as well, we should go through a re-brand process because, you know, "Dash is Digital Cash" is not the main use case anymore. And maybe we should just merge with Horizen because they already have two paid node types with encryption.

If this goes through - and I suspect it will - I might as well quit accumulating dash and rewards, just use them to buy other tokens more worthy of my attention.
 
The chance to be able to stop a quorum is 0.13% for the top MNO with 40% more Dash with the 1K solution. It's at 0.03% for the 4K solution and 0% with the 10k solution. So if you are interesting in decentralization for a security reason then you should prefer 10k over 4k over 1k. While this is counterintuitive it's still the truth. It's because of how probabilities work.

Could you elaborate on this? How can a quorum be stopped?
Are we talking about a malicious actor that remains a permanent quorum member and does not want to store some specific data into the DashPlatform (that all the rest are storing)?
Is this the way to stop the quorum?

Sorry if this question is already asked and answered.
 
All other solutions (even the 4K HPM solution) are all extremely bad.

Okay, let me explain what we would do in the 4K scenario. We would probably just create 4 quorums / day. In that case we would have 4 * 365 = 1460 tries.


(1 - (1 - 0.0003)^1400) = 34.3%

This basically means that IF the top masternode owner would somewhat get 40% more Dash than they currently have they would have a 34.3% chance of being about to stop the chain at least once a year. Not taking control of it.

While this isn't great, let's be real here. The main thing we need to protect against isn't them trying to do this attack willingly, it's more that all of a sudden they decide to take down their nodes for some reason. We can't have them taking down their nodes stop platform.
 
Lets talk a bit about our largest Dash whale being able to stop the Platform chain, just by taking down all of its Platform nodes :

Who is our largest whale currently ? Binance (according MNOwatch.org)
How many Nodes does Binance have ? 270 nodes (according MNOwatch.org)
How many dash does Binance have on their exchange? I think i read something like 400.000 dash ?

Note : there is a very large difference to how much this Dash whale owns with regards to dash and how many nodes he has setup up according MNOwatch.org
A difference will remain, even if this Dash whale buys more dash to setup more nodes

To add 40% : 160.000 dash
To add 20% : 80.000 dash

This Dash whale also promote Dash staking on its exchange to its users worldwide (in most cases a higher ROI, then we currently have with our own masternodes)

These are our current Platform solutions :

Platform on all nodes
1K
4K HPM
10K HPM

Only the 1K solution offers this whale the option to either run a normal 1K node or a 1K Platform node.

Would Binance keep using the normal 1K nodes or setup Platform 1K nodes, taking into account the increased hardware requirements and increased cost factor ? I am not sure. I would assume Binance would stick with the normal 1K nodes.

But does it even matter ? Not everything that Binance owns or even further adds to its possession will be converted to nodes. And for the nodes that Binance does have, Binance also have a strong incentive to keep them active (to provide staking rewards to its users).

If we no longer focus on the willingly attacks aspect (with the attacking Platform 365 days a year part) and instead focus on a sudden move of Binance to shutdown all of its nodes at once, then we should also look at the motive and explore ways to stop large Dash whales from possibly stopping the Platform chain by the 'stopping all their nodes at once' vulnerability. This should be done through additional coding to protect Platform against this.
What we should not do, is just rely on a centralized solution to control this situation and have devs develop tunnel vision towards that centralized solution.

You could for excample introduce an element of randomness with regards to Platform nodes becoming inactive, to prevent large Dash whales to shutdown all their Platform nodes at once. Or you could introduce a time lock for Platform masternodes, to prevent them from shutting down all at once. There are i am sure more solutions to address this, then just pointing to a centralized solution.
 
Last edited:
Could you elaborate on this? How can a quorum be stopped?
Are we talking about a malicious actor that remains a permanent quorum member and does not want to store some specific data into the DashPlatform (that all the rest are storing)?
Is this the way to stop the quorum?

Sorry if this question is already asked and answered.

Basically the quorum would stop if more than 34 members out of 100 were to turn off their nodes within the same day. The MNOs don't even need to be malicious... This is currently one of the systems greatest flaws. Fixing it will take time and I don't want to delay Platform any more. However we probably will slightly improve it to some smaller time length. This is easiest to do with the 10k system.
 
Basically the quorum would stop if more than 34 members out of 100 were to turn off their nodes within the same day. The MNOs don't even need to be malicious... This is currently one of the systems greatest flaws. Fixing it will take time and I don't want to delay Platform any more. However we probably will slightly improve it to some smaller time length. This is easiest to do with the 10k system.

How long does the quorum usually run ? And would it help if we make the quorum larger in number ? (which could possibly be done on the Platform on all nodes solution or the 1K solutions, because the Platform nodes are larger in number there).

Honestly, i would expect such a large vulnerability to quorums to be very high on the agenda of devs to fix. And certainly to fix this before launch of Dash Platform.
If this is about launching Dash Platform with such a vulnerability to qourums or taking the time to fix it before launching Dash Platform, than be all means take your time to fix it. Just give it the highest priority and keep us updated about it.
 
Last edited:
@qwizzie larger quorums will require more bandwidth and processing power, 100 is kind of a sweet spot, but we could potentially go as high as 200, though the problem is that the higher you go the more powerful the nodes would need to be.

So why would Binance (the largest exchange of the world) have a motive to take down all its nodes ?
To upgrade them.

You could for example introduce an element of randomness with regards to Platform nodes becoming inactive, to prevent large Dash whales to shutdown all their Platform nodes at once. Or you could introduce a time lock for Platform masternodes, to prevent them from shutting down all at once. There are i am sure more solutions to address this, then just pointing to a centralized solution.
There is a lot of stuff we can do... but we need to release. The solutions presented here were low cost and in my opinion high reward.
Things like unbonding times (which a lot of other projects have) could be potentially controversial as well.
 
@qwizzie Sorry I didn't realize it earlier, but 1k split solution can't work because it is impossible to split rewards. Since everyone would be running core, it is impossible to take rewards from core to give them to Platform and have a market equilibrium.

Imagine rewards are going 50% to core and 50% to platform, with everyone running core. There is no way for the number of nodes to stabilize, basically everyone would then run platform or lose 50% of their rewards.
 
Back
Top