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

[QuantumExplorer]

I need to get back to coding, so I won't be replying here for the coming few days. There will be a AMA with Joel on Friday, so if you want you can come ask me your questions in there. Thanks everyone.

 

[seanjae]

Seems to me we can have the best of all worlds with the 1k mn construct, because not all will upgrade. At best, I’d say we get 1,000 mnos who upgrade immediately following release. This might be optimistic given the track record of the project. This dynamic sets up the same construct as the 4k, 10k ideas where even if platform has an issue the classical nodes running would carry the system. So the whole security discussion is addressed.

The market theory discussion now actually makes sense; all nodes are 1k and just some are platform nodes. If it’s determined platform is a success and the fees earned are worth the effort to upgrade more node owners will. This will continue until an equilibrium. Even then, there will be folks who don’t care about platform (which gives time to figure out breaks in platform if they happen) and will stay classical nodes. Also, hosting services will likely increase host rates if you want a platform node, and most aren’t going to pay that until they see the benefits.

Again, it seems like we get all the desired outcomes by simply releasing platform and letting the users adjust to it. No collateral adjust, last minute guessing necessary.

Also, the whole security is an important issue and we don’t need an audit because it’s a waste of money because we know the issues makes little sense. I’d adjust fire on that messaging. But, super glad the team knows the vulnerabilities.

 

[qwizzie]

Seems to me we can have the best of all worlds with the 1k mn construct, because not all will upgrade. At best, I’d say we get 1,000 mnos who upgrade immediately following release. This might be optimistic given the track record of the project. This dynamic sets up the same construct as the 4k, 10k ideas where even if platform has an issue the classical nodes running would carry the system. So the whole security discussion is addressed.

The market theory discussion now actually makes sense; all nodes are 1k and just some are platform nodes. If it’s determined platform is a success and the fees earned are worth the effort to upgrade more node owners will. This will continue until an equilibrium. Even then, there will be folks who don’t care about platform (which gives time to figure out breaks in platform if they happen) and will stay classical nodes. Also, hosting services will likely increase host rates if you want a platform node, and most aren’t going to pay that until they see the benefits.

Again, it seems like we get all the desired outcomes by simply releasing platform and letting the users adjust to it. No collateral adjust, last minute guessing necessary.

Also, the whole security is an important issue and we don’t need an audit because it’s a waste of money because we know the issues makes little sense. I’d adjust fire on that messaging. But, super glad the team knows the vulnerabilities.

There is one problem with this : at some point the 1K masternodes (current masternode system) that do not want to support Dash Platform and have no intention to upgrade to v19 (Dash Platform), will get PoSe banned. Unless we allow both v18 masternodes (Classical) and v19 masternodes (Dash Platform) to co-exist.
Or unless DCG finds a way where v19 masternodes can opt-out of supporting Dash Platform, without getting PoSe banned. That would then also lead to Classical 1K masternodes and Platform 1K masternodes (both on v19)

But something tells me both will be difficult to implement, most likely leads to delay and may have some disadvantages as well (it would fracture / divide the masternodes for example)

 

[seanjae]

There is one problem with this : at some point the 1K masternodes (current masternode system) that do not want to support Dash Platform and have no intention to upgrade to v19 (Dash Platform), will get PoSe banned. Unless we allow both v18 masternodes (Classical) and v19 masternodes (Dash Platform) to co-exist.
Or unless DCG finds a way where v19 masternodes can opt-out of supporting Dash Platform, without getting PoSe banned. That would then also lead to Classical 1K masternodes and Platform 1K masternodes (both on v19)

But something tells me both will be difficult to implement, most likely leads to delay and may have some disadvantages as well (it would fracture / divide the masternodes for example)

Same problem exists with the 4K 10k ideas. Apparently it’s 15 minutes of coding (as quoted above) to allow for this state to exist.

 

[qwizzie]

Same problem exists with the 4K 10k ideas. Apparently it’s 15 minutes of coding (as quoted above) to allow for this state to exist.

Interesting ... i did not think of that.

I think i read too hastily over your 'This dynamic sets up the same construct as the 4k, 10k ideas where even if platform has an issue the classical nodes running would carry the system. So the whole security discussion is addressed. ' line.

I like your idea.

 

[GrandMasterDash]

Let's imagine just for a second that Platform were to go down taking down all nodes with it. Chainlocks would fail, IS would fail, Coinbase would no longer process deposits... This could be catastrophic. Most blockchains have glitches when they are released. So if I just release and see and then something bad happens, pitchforks will be out. I am proposing a high value extremely low cost option that allows us to release with the utmost safety.

I really don't think this is true, it doesn't have to be black and white. On initial release, consensus could be built to exclude most nodes with a gradual rollout, allowing enough time for fixes. You should know this, so I'm left wondering why you didn't voice such an option.

 

[seanjae]

Interesting ... i did not think of that.

I think i read too hastily over your 'This dynamic sets up the same construct as the 4k, 10k ideas where even if platform has an issue the classical nodes running would carry the system. So the whole security discussion is addressed. ' line.

I like your idea.

I’m playing catch up to this discussion, but the presentation did catch me by surprise and then left more questions than answers. Seems like we’re chasing the ‘they’ of “if we build it they will come” before we’ve built it. The fees and tps won’t be as briefed (ie all mnos running today won’t upgrade to run platform) which means it will be cheaper and faster then presented. Thus, negating the increase in collateral ideas because the outcomes are similar.

To me it’s simple, we launch (build it) and see who shows up (they), then adjust fire from there.

 

[Semarg]

...But at the same time we can't destroy such a monumental effort because a few people are tired of waiting and refuse to talk about the starting parameters of our system.

"Starting parameters" for you - huge portion of personal wealth for many.

 

[strophy]

Thanks @QuantumExplorer for engaging with the questions here in good faith on a weekend! Really appreciate you taking the time to explain the concepts in the video and responding here so actively.

If a platform bug somehow completely takes Masternodes down (not just platform, but core too). In the "every node runs platform choice" that means pretty much all nodes would go down. In the 4k choice only 20% of nodes go down. In the 10k choice only 10% of nodes go down. So yeah one solution is quite a bit safer.

My question is about the hypothetical scenario where something bad happens on platform and takes down core on the same node with it. On our development networks, we cannot remove more than 10% of nodes at a time, or there is a risk of quorums breaking. Is this risk mitigated on larger networks, or would platform going down and taking core with it still be able to prevent IS/CL locks even if only 10% (10k nodes) to 20% (4k nodes) go down? Or would the HPMNs not participate in the IS/CL quorums?

 

[peter]

would platform going down and taking core with it still be able to prevent IS/CL locks even if only 10% (10k nodes) to 20% (4k nodes) go down? Or would the HPMNs not participate in the IS/CL quorums?

From Sam's (IMHO good) explanations, I understand the following (that could be completely wrong):
1.) Core and Platform are 2 different software packages, and run independently.
2.) Core is responsible for IS/CL and so on.
3.) Platform is responsible for contact information, running DAPPs and so on.
4.) If Core and Platform can be linked to the *same* collateral (1k option), then all MNOs will certainly try to run both software packages.
5.) If Core and Platform have to use *different* collaterals, every MNO will make is own choice between Core or Platform.
6.) Answer to your question: HPMNs would certainly not run Core, and so they would certainly not participate in the quorums.

Point 4 means a risk, because when the Platform package eats up all memory, destroys the SSD, freezes the OS, eats up all CPU and/or network bandwidth, or whatever, then Core will go down too.

So, whenever a collateral, that is used by Core, cannot be used by Platform, and inversely, this risk is mitigated.
If the amount is the same (1K/1K option), it will be a bit more complicated, because Platform needs to check, if Core uses the TX, and the other way round. If the amount is different (HPMN option), it will be easy.

 

[QuantumExplorer]

My question is about the hypothetical scenario where something bad happens on platform and takes down core on the same node with it. On our development networks, we cannot remove more than 10% of nodes at a time, or there is a risk of quorums breaking. Is this risk mitigated on larger networks, or would platform going down and taking core with it still be able to prevent IS/CL locks even if only 10% (10k nodes) to 20% (4k nodes) go down? Or would the HPMNs not participate in the IS/CL quorums?

While I was telling infrastructure team to not take down more than 10% at a time, I was oversimplifying something more complicated and making sure the probability of something going wrong was close to 0%. This is more because if you actually had taken down 20% per day, but done so 23 hours after the previous cycle and this had been aligned to right after a cycle started and then right before a cycle started, issues would have arisen.

If 20% of the network would to come down, there is a very high probability that IS locks would be fine, and almost guaranteed that CLs would be fine. Within 12 hours all IS lock quorums should work again if one had gone down due to extremely bad luck (I think something less than 1 in a million).

 

[QuantumExplorer]

6.) Answer to your question: HPMNs would certainly not run Core, and so they would certainly not participate in the quorums.

HPNS do run indeed run Core.

5.) If Core and Platform have to use *different* collaterals, every MNO will make is own choice between Core or Platform.

The choice if from running Core, or Core and Platform.

 

[QuantumExplorer]

I really don't think this is true, it doesn't have to be black and white. On initial release, consensus could be built to exclude most nodes with a gradual rollout, allowing enough time for fixes. You should know this, so I'm left wondering why you didn't voice such an option.

DCG doesn't choose nodes for platform, they are selected randomly. It would be very bad for security if DCG were to select nodes. And there's no way to prove nodes are running platform before the whole system starts.

 

[QuantumExplorer]

"Starting parameters" for you - huge portion of personal wealth for many.

And the latter for me as well. Need to point this out so people know that our incentives should be aligned.

 

[qwizzie]

@QuantumExplorer

What about seanjae's post with regards to setting up 1K masternodes with the same construct as with 4k / 10k masternodes (by coding that state into existence) : could that technically work and would that increase security, when chosing the 1K solution ? Because then there would be classical 1K nodes (to possibly fall back to in case of a network threathening bug) and platform 1K nodes. Platform 1K nodes would require higher hardware requirements, while classical 1K nodes could run on current hardware requirements.

See : https://www.dash.org/forum/threads/...gh-performance-nodes.53374/page-4#post-232254

Perhaps a simple line in the dash.conf could make a node either a Platform 1K node or a classical 1K node
(platform=1 versus platform=0)

There is one thing that concerns me with both the above described 1K masternode solution and the 4k / 10k masternode solution : it will be more easy to DDoS attack the 1K nodes and the 4k / 10k nodes as well (all of them end up with smaller groups, then our current one large masternode group system).

Dash experienced DDoS attacks in the past and with so much credits circulating on Dash Platform, it will form an attractive target for hackers seeking to exploit or disrupt Dash.

 

[kot]

If you consider yourself the opposing voice in this scenario. Try to imagine yourself in my scenario. You talk about a comfort zone. You think it's a comfort zone when Glenn has left and I need to take control of the bank accounts in order to actually have people paid? Do you think it's a comfort zone when I'm being attacked on this forum for bringing up what I think will be the most secure and fast way with lowest fees ensuring success? Do you think it's a comfort zone when I'm the only one in our team who can actually do some of the coding work with all others burned out on some parts? No, this is not my comfort zone. But it is what I must do because failure is not an option.

The situation you are in is not a coincidence and did not happen over the weekend.
We were having conversations like this when I was still in the company. You have chosen to listen only to yourself and to not accept any feedback other than enthusiastic.

Here you have multiple voices expressing concerns about the new ideas that appeared out of nowhere. Maybe it is worth to consider them as valuable input and not doing the same thing over and over again?

EDIT.
Just to make sure, I am properly understood (as I know my language is sometimes not very precise).
I am not attacking you and putting blame on you. I am trying to suggest different approach to the one that has failed.
You are a great engineer and developer Sam, you are very nice person too, but it doesn't make you automatically a great manager and it creates problems in the specific DCG environment (with low budgets, cultural issues, broken timelines, scope changes, unknown tech, knowledge silos and low commitment in some cases). Actually, I think that this nice part of you makes you struggling in the management field. The decisions you have to make in such company are most of the time difficult or even shitty from the emotional perspective. But they are necessary to be made - avoiding making hard decisions leads to this:

Do you think it's a comfort zone when I'm the only one in our team who can actually do some of the coding work with all others burned out on some parts?

This is VERY bad. It was the same two years ago, it was the same a year ago and it is now. It became a status quo.
Manager shouldn't be the one coding. Manager could help with programming from time to time but his role is to work on problems, make improvements, make his team effective and productive by making decisions and applying changes (most of the time painful changes, if the things don't work). Based on what you wrote, nothing changed and changes are desperately needed - staff changes, cultural changes and org changes.
You are trying to save the day by working your ass off and coding - this is great and awful at the same time, Why? Because you are damn good at technical matters (actually you are probably the best dev I have ever met). But the management part is suffering. Staff is burned out, timelines are not met, scope keeps creeping and product is still not released.
I actually think you should drop the role of CTO and focus yourself on development and architecture - this is where you excel. You will get your fame and glory in this field, but you will only get frustration as a manger imho.
Let some other person do the management work as it is becoming a slippery slope for you. And to be clear - I am not suggesting myself. My days in DCG are over.

 

[Adding1kDash]

Dashplatform taking down, regular masternodes ?
That should not be the case if the software runs properly, even in crappy OS like windows, its is almost never the case anymore !
If there is a fear that the software may take down everything, than just lower the rewards for Dashplatform to a number that makes sure that innitially not everyone is will to run it, due to lack of suffient pay.

Furthermore, all these theoricial equations are a nice tool. But we are humans !!!!! and there is a simple saying, power corrupts and absolute power corrupts absolutely. The smaller the number the more likely, corruption will take place ! We know in crypto corruption has already taking place with 101 supernodes pos crypto's ! 180 HP masternodes is therefor a 100% NOOOOOOOOOOOOOOOOOOOOOOO. I will certainly step out, and I will step out very embarrassed as well, as I have debated both in real life and online that Dash is one most decentralised crypto currency's out there, and now so close too seeing username accounts, it just say oh well 0,58 innitial cost is way to high, lets just be centralized instead ?

Also understand once centralisation takes a hold, re decentralisation is extremely difficult, and will likely not happen, because the corrupt colluders now have found ways to contact eachother, and what is HP masternode owner going to do ? give away all his dash ?!?
Just because sharding is not yet ready, don't throw the baby out with the bathwater


side note:
I can understand Dash has become like a child, and its hard to let go of the child and finds its own way, we just need to accept that problems can and will be a thing, but lets take of it's trainwheels and let it fly. What happens happens we (investors) are okay with it !. A broken promise of full decentralisation is not acceptable do !

 

[xkcd]

I have a suspicious feeling that Sam is more interested in the Discord MNO channel and feedback he is receiving from masternode whales there, then from the very negative feedback he is receiving here. Kinda explains his initial decision to launch three decision proposals right away, despite the very negative response in here.

Anyone keeping taps on that Discord MNO channel ? What is the mood / preference there ?

I have a suspicious feeling that you are more interested in the Forums than the Discord and ignore all the positive (ROFL) feedback in the Discord and dwell on the negativity in the forums.

Stop being so paranoid, Sam is getting similar types of questions on all channels, the forum, the discord, twitter, all over the place, pull your head out of your ass and take a deep breath, the fresh air will do you good.

 

[xkcd]

"reallocating that Platform security audit funding to DCG Infrastructure" -> Well it mostly went to the core audit. Which basically didn't reveal any security flaws that we didn't already knew existed (2 minor issues, we will get around to fixing them).

Dude, do you know how many bugs I found in Core? I think at least 3 so far since before the release of v18 and another just last week. I agree audits are great and we should do them, but they won't catch many bugs. Was SOL audited, how about BSC? Static analysis is super hard, especially when you are looking at the code cold, real cold.

 

[QuantumExplorer]

Dude, do you know how many bugs I found in Core? I think at least 3 so far since before the release of v18 and another just last week. I agree audits are great and we should do them, but they won't catch many bugs. Was SOL audited, how about BSC? Static analysis is super hard, especially when you are looking at the code cold, real cold.

Exactly what xkcd said. He's finding bugs/issues because he cares. While you might fall on an external auditor that really cares, most of the time it is a task for them, maybe they will do good because it is their professional duty, but it's not fueled by passion like it is for many long timers (and many new hires too) in Dash.