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.
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)
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.
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.
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.
...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.
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.
From Sam's (IMHO good) explanations, I understand the following (that could be completely wrong):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?
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?
HPNS do run indeed run Core.6.) Answer to your question: HPMNs would certainly not run Core, and so they would certainly not participate in the quorums.
The choice if from running Core, or Core and Platform.5.) If Core and Platform have to use *different* collaterals, every MNO will make is own choice between Core or Platform.
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.
And the latter for me as well. Need to point this out so people know that our incentives should be aligned."Starting parameters" for you - huge portion of personal wealth for many.
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.
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?
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 ?
"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.