This is just an example. You could also say 45% / 40% / 5% / 10%, or whatever...
Should Platform run on all nodes or should Platform run only on High Performance nodes ?
- Thread starter qwizzie
- Start date
I like this idea rather than 50-50 block reward split between MNs and Platform nodes. This way the platform nodes will be compensated relative to the value it brings to the dash value proposition (relatively little at first). If you pay less for hpmn with a smallre block reward you'll get less hpnm which is the stated desire. Coherent. What's not clear is how collateral plays into this.
This has been a great discussion, thanks to qwizzie for starting this and the DCG for providing their input. Great arguments already made against increasing collateral and have few opinions/suggestions that would like to share, please ignore if they do not make sense.
1. Platform disrupting core services: Not sure how complicated to implement this, but there were concerns about platform bugs bringing down the core. If the platform code is decoupled with core, is it possible to run an optional platform node on a different server using the same masternode key at least initially? This does require maintaining 2 servers but this will not disrupt core services until the platform is stabilized. And platform nodes should only be compensated with platform credits and can also implement time locks as someone suggested. Some other projects also implemented benchmarks for hardware requirements.
2. High fee concern: Fee should not be the reason to increase collateral. If high fee is indeed a concern, please reduce the charges/kb in the storage calculations, initially there might be quite a number of masternodes that are willing to run a platform node for loss for decentralization sake, (there are thousands of BTC nodes without any pay). As per calculations, ideal number for platform nodes is 250 to 400 and I think this number can be easily achieved with normal masternodes.
3. Collateral increase: Increasing collateral for platform nodes is breaking social contract. Let me explain, only income that a masternode receives currently is from block rewards and they go down as years pass by, I am sure number of people invested in the masternodes thinking that they will be able to earn platform fees and this change will deprive that. As history suggests, since the voter participation is really low, whales tend to sway the results. Increase in collateral definitely is advantageous to whales and is not a good proposal unless there is a greater voter participation and definitely not easy to reduce the collateral for platform nodes as suggested in the future as nobody wants to maintain more servers for the same reward.
1. Platform disrupting core services: Not sure how complicated to implement this, but there were concerns about platform bugs bringing down the core. If the platform code is decoupled with core, is it possible to run an optional platform node on a different server using the same masternode key at least initially? This does require maintaining 2 servers but this will not disrupt core services until the platform is stabilized. And platform nodes should only be compensated with platform credits and can also implement time locks as someone suggested. Some other projects also implemented benchmarks for hardware requirements.
2. High fee concern: Fee should not be the reason to increase collateral. If high fee is indeed a concern, please reduce the charges/kb in the storage calculations, initially there might be quite a number of masternodes that are willing to run a platform node for loss for decentralization sake, (there are thousands of BTC nodes without any pay). As per calculations, ideal number for platform nodes is 250 to 400 and I think this number can be easily achieved with normal masternodes.
3. Collateral increase: Increasing collateral for platform nodes is breaking social contract. Let me explain, only income that a masternode receives currently is from block rewards and they go down as years pass by, I am sure number of people invested in the masternodes thinking that they will be able to earn platform fees and this change will deprive that. As history suggests, since the voter participation is really low, whales tend to sway the results. Increase in collateral definitely is advantageous to whales and is not a good proposal unless there is a greater voter participation and definitely not easy to reduce the collateral for platform nodes as suggested in the future as nobody wants to maintain more servers for the same reward.
Without an additional collateral for the HPMNs, almost all MNs (because hardware is cheap and gets cheaper every day) would switch to HPMNs with the already mentioned downsides.
switch or run both? if people want to run lighter hardware they may not want to run both.
small enough block reward will insure few people take up HPMN and if they do it is a bonus to the network.
small enough block reward will insure few people take up HPMN and if they do it is a bonus to the network.
No, platform is not half baked. We will have many features that no other blockchain will have, so you need to dispel any notion that the work that we release will not be top notch.
High fees are an issue, but even if they weren't here are the problems with non HPMN solutions:
The everyone runs platform solution :
We would be forcing everyone to run platform causing ROI to go very much down as hardware requirements go up, a lot of people would probably skimp on their hardware requirements. If platform does manage to start, then a lot of people would start to complain because they weren't getting rewards, because their nodes would be too weak (eventually). Look, it might work, I just think it's a lot more risky than other scenarios. If the network decides to go this option, all I can say is that we will see and I'll pray to have been wrong. And then we have the downside that if something goes terribly wrong with platform it could stop the entire masternode network.
Any solution not forcing platform while maintaining 1k collateral :
This would lead to heavily centralization. All the math shows this. 1 entity could most likely stop the chain depending on how many initial rewards we send to platform. There is even risk with massive centralization of funds being able to be stolen if 1 entity could control over 2/3rds of the network. To me this is very scary. I am okay to code up solutions that would allow the chain to potentially stop if the network voted decided that was the solution they liked the best, but I would never be okay with a solution where funds could be stolen. People calling for these solutions in the name of decentralization are ill informed and might be unwilling to listen to reason.
When we see all the downsides from these solutions, and then HPMNs also just so happen to have really low fees, allow the whole network to have higher ROIs, take very little work to code up, obviously we will be pushing for these solutions, because they work better while the others at least to me are scary.
In the HPMN solutions money is not being taken from normal masternodes to be given to HPMNs.
If you earn 1.4 Dash 5 times a month, it's the same as if you were to earn 0.7 10 times a month.
With the HPMN solution, the HPMNs participate far less in core services for their collateral. This leads to non HPMNs being rewarded far more for Core services.
There is a natural market balance that occurs.
What's even more is that excess fees from platform would flow because of this balance to normal masternodes.
We calculated that if you want the highest return you should vote on the highest collateral solution, and provided those numbers somewhere in this thread.
We have the opportunity to make platform into a business, where if successful fees would generate revenue for the entire network. Not just speculation, actual fees that pay out. I think that the high fees is not the greatest concern, but low fees while still making the masternode network a lot of extra money could be nice. This is why I think the 10k solution is very nice (though I still like the 4K solution because of the accessibility). We can put fees quite higher than they cost the network and STILL they would be very low compared to other chains.
Platform uses core services, and needs them locally, so this is not an option.
That's my guess. Ryan did this estimation a few years ago, about 4 MNs in average, that seems like good estimate to me and things didn't change much since then.
Could you explain it in details? Or give a link if it's already mentioned. I didn't notice.
How come keeping collateral 1k leads to centralization??
An alternative to consider:
1. Make running platform services optional
2. Require collateral lockup to run a platform masternode.
3. Maintain 1,000 DASH collateral requirement for all masternodes:
- 1,000 DASH for core masternodes (as current/normal)
- 1,000 DASH locked for platform masternodes (see below for lock time considerations)
4. Launch conservatively and limit participation (do a beta launch)
- high initial lock time period (e.g. 1 year)
- low initial platform node allocation (e.g. 10% of masternode allocation)
5. Refine over time
- observe data (costs, performance, stability, which nodes have upgraded, etc)
- fix bugs and adjust consensus variables until dialed in:
- decrease lock time period (e.g. to 6 months) to increase node count (e.g. to 400 nodes)
- increase platform allocation (e.g. to 20%) to increase node count (e.g. to 600 nodes)
Example:
(numbers not set in stone, just for illustration)
Why?
1. Increasing collateral requirements is coming out of nowhere and it seems many MNOs don't like the idea.
- Some don't like being denied the opportunity to operate the very thing they've been waiting for and supporting for many many years.
- Some don't like it because it sets up an "elite" class above normal masternode owners, even if they can be a part of the new class.
- Some don't like it for security reasons (more on that below).
2. This solution satisfies the main stated goals of the "high performance masternode" proposal:
- It reduces platform costs by lowering the platform node count.
- It gives platform node operators the financial incentive/ability to operate high performance nodes.
- In the case of a catastrophe, platform nodes won't take down the payment network, since node count is limited.
- It can mitigate the risk of multiple platform nodes dropping off with staggered time locks.
3. It is arguably more secure than the "high performance masternodes" proposal
- We can fine tune the node count as high as we want, in an easier way than adjusting allocation requirements.
- Requiring locked collateral reduces the risk of centralized exchanges (e.g. Binance) and 3rd party custodial operators operating many platform nodes. 3rd party custodians likely can't lock their customers' funds. This would likely increase the number of entities operating platform nodes. Entity count is far more important than node count for security.
- Other large whales (besides 3rd party custodians discussed above) would likely not lock up all their funds either. They would probably either stagger their collateral locks, or simply operate a mix of normal and platform nodes to maintain liquidity of some portion of their stash.
4. It is more "fair", by making operating a platform node financially accessible (or at least far more so). Even though "fairness" is subjective and not measurable, it's still one of the most important factors in terms of how the project is viewed.
5. It is more conservative. Dash has always had a 1,000 DASH masternode collateral requirement. Adding locking is a less "heavy handed" change than 4x-ing or 10x-ing the cost to run a masternode.
5. This would give the whole network (not just platform nodes) more economic security and certainty because we would have hard data about a portion of Dash that is actually locked (not just collateralized in masternodes) for any given time (now and into the future). This could bring more investor interest to Dash in the same way this does for vesting (locking) schedules for tokens and traditional equities.
6. In addition to the increased quantity and diversification of entities running platform nodes discussed in item 3 above, locking would also increase the quality of entities running platform, since only the most committed (not just the richest) node operators will be willing to lock their collateral. The whole point of security considerations is to prevent attacks from bad actors. If you can reduce the number of bad actors in your node set then lower count is not necessarily lower security - it can actually yield higher security. MNO quality > MNO quantity.
Poll:
One concern with this is: will MNOs be willing to lock their collateral, or will they be just as upset with that new requirement as they are with the increased collateral requirement? A few days ago I created a poll on Discord to assess this willingness, and I think the numbers speak for themselves:
So, should we explore this idea more? I'm not fully convinced it's the best option, but I think it's worth fleshing out, to possibly include it in next month's proposed options.
For the record, I'm more in favor of the 4k or 10k collateral platform node options than requiring all masternodes to run platform, so big thanks to Sam and DCG for bringing up and discussing this difficult decision.
Also, I plan to chat with @virgile about security calculations. I've looked at the modifications he made to my original model (screenshot above), and they mostly make sense to me, but I need a couple clarifications before I can model my proposed solution in a similar way that he did for DCG.
1. Make running platform services optional
2. Require collateral lockup to run a platform masternode.
3. Maintain 1,000 DASH collateral requirement for all masternodes:
- 1,000 DASH for core masternodes (as current/normal)
- 1,000 DASH locked for platform masternodes (see below for lock time considerations)
4. Launch conservatively and limit participation (do a beta launch)
- high initial lock time period (e.g. 1 year)
- low initial platform node allocation (e.g. 10% of masternode allocation)
5. Refine over time
- observe data (costs, performance, stability, which nodes have upgraded, etc)
- fix bugs and adjust consensus variables until dialed in:
- decrease lock time period (e.g. to 6 months) to increase node count (e.g. to 400 nodes)
- increase platform allocation (e.g. to 20%) to increase node count (e.g. to 600 nodes)
Example:
(numbers not set in stone, just for illustration)
Why?
1. Increasing collateral requirements is coming out of nowhere and it seems many MNOs don't like the idea.
- Some don't like being denied the opportunity to operate the very thing they've been waiting for and supporting for many many years.
- Some don't like it because it sets up an "elite" class above normal masternode owners, even if they can be a part of the new class.
- Some don't like it for security reasons (more on that below).
2. This solution satisfies the main stated goals of the "high performance masternode" proposal:
- It reduces platform costs by lowering the platform node count.
- It gives platform node operators the financial incentive/ability to operate high performance nodes.
- In the case of a catastrophe, platform nodes won't take down the payment network, since node count is limited.
- It can mitigate the risk of multiple platform nodes dropping off with staggered time locks.
3. It is arguably more secure than the "high performance masternodes" proposal
- We can fine tune the node count as high as we want, in an easier way than adjusting allocation requirements.
- Requiring locked collateral reduces the risk of centralized exchanges (e.g. Binance) and 3rd party custodial operators operating many platform nodes. 3rd party custodians likely can't lock their customers' funds. This would likely increase the number of entities operating platform nodes. Entity count is far more important than node count for security.
- Other large whales (besides 3rd party custodians discussed above) would likely not lock up all their funds either. They would probably either stagger their collateral locks, or simply operate a mix of normal and platform nodes to maintain liquidity of some portion of their stash.
4. It is more "fair", by making operating a platform node financially accessible (or at least far more so). Even though "fairness" is subjective and not measurable, it's still one of the most important factors in terms of how the project is viewed.
5. It is more conservative. Dash has always had a 1,000 DASH masternode collateral requirement. Adding locking is a less "heavy handed" change than 4x-ing or 10x-ing the cost to run a masternode.
5. This would give the whole network (not just platform nodes) more economic security and certainty because we would have hard data about a portion of Dash that is actually locked (not just collateralized in masternodes) for any given time (now and into the future). This could bring more investor interest to Dash in the same way this does for vesting (locking) schedules for tokens and traditional equities.
6. In addition to the increased quantity and diversification of entities running platform nodes discussed in item 3 above, locking would also increase the quality of entities running platform, since only the most committed (not just the richest) node operators will be willing to lock their collateral. The whole point of security considerations is to prevent attacks from bad actors. If you can reduce the number of bad actors in your node set then lower count is not necessarily lower security - it can actually yield higher security. MNO quality > MNO quantity.
Poll:
One concern with this is: will MNOs be willing to lock their collateral, or will they be just as upset with that new requirement as they are with the increased collateral requirement? A few days ago I created a poll on Discord to assess this willingness, and I think the numbers speak for themselves:
So, should we explore this idea more? I'm not fully convinced it's the best option, but I think it's worth fleshing out, to possibly include it in next month's proposed options.
For the record, I'm more in favor of the 4k or 10k collateral platform node options than requiring all masternodes to run platform, so big thanks to Sam and DCG for bringing up and discussing this difficult decision.
Also, I plan to chat with @virgile about security calculations. I've looked at the modifications he made to my original model (screenshot above), and they mostly make sense to me, but I need a couple clarifications before I can model my proposed solution in a similar way that he did for DCG.
absolute no from me to lock collateral. Would rather have 4K/10k solution.
The whole premise of crypto is your keys your coins. Not sorry your keys but you can't touch. Additionally this solution does not fix most cheap skates running platform on the same spec hardware as their 1k node and providing a bad user experience or halting platform all together.
The absence of a robust Proof of Service on Platform is not half-baked? What are the implications if we remove Proof of Service from Core, the payment side, or is this different?
You have argued that asking the network about HPMNs is the fair and reasonable action to take. So let me ask, did I miss the proposal from DCG when the current PoSe scores were added to Core? Because from what I remember, it was a hard fork and we had to suck it up. How could it be that PoSe scores were forced upon us without a proposal? Do you accept that PoSe scores for Core are essential? - if so, then why not PoSe scores for Platform?
You keep saying high fees is an issue without any hard evidence. Indeed, right at the beginning of your post you said, "We will have many features that no other blockchain will have, so you need to dispel any notion that the work that we release will not be top notch." When you have a "top notch" product with unique features and no competitors, how do you deduce the fees must be low?? Contrary, you have a license to print money for the benefit of the network.
When and where did you ever hear these complaints from masternodes? This was always the deal, that one day masternodes would be profitable to pay for custom made hardware acceleration located in data centers around the world. You say these were unrealistic promises made by Evan Duffield X number of years ago - and maybe you're right (or not) - but if we go with the HPMNs option now, you will of never proven us wrong. You say it's just a few lines of code to implement so once you've proven how inefficient Duffield's vision was, it will take you no time at all to fix it. There are so many moving parts, none of us can possibly know for sure what type of customers / developers we're going to attract and the limits they are willing to accept. People still use Ethereum and Solana and we're all quite aware of their limits.
How can we be sure the lower fees won't attract spam and slow down the network?
Who's to say that HPMN owners wouldn't "skimp on their hardware requirements"? It might be said, a little insulting to shrimp masternode owners that they are more prone to stinginess. A robust PoSe score is the only metric that matters, the collateral is there for reasons of Sybil attacks.
I'm sure most hosting services are fiat denominated, even when they accept crypto payments. If the current price of dash was 10x or 20x, would you still be making these arguments about ROI? Because the way I see it, you are talking about ROI relative in dash units whereas all of us here are renting in fiat denominated prices. The ROI means nothing if dash is low in fiat terms. In which case, octopus masternode owners might also be stingy.
This is emotional blackmail. This possible scenario is literally down to DCG's designs and implementation. You can't and shouldn't hold MNOs responsible for this. When it goes down, my finger is well and truly pointing in DCGs direction and I will not accept, "oh, but the masternodes took us in this direction". You are paid for technical excellence, nothing less.
You sadly have no idea what you are talking about. In Core, you are punished when you do not join a quorum. This is the Core Proof of Service. Notice how it does not include any punishment for not servicing Mobile phones with blockchain data? Core does not have a robust Proof of Service either and yet... still works. So why is Platform different? In Platform the requirements are higher, and the storage costs are much much higher (made up by fees), so users will have a much greater incentive to cheat the system. And them cheating the system has much worse consequences, as platform is more serviced base then Core.
Not sure you are actually reading, that and following paragraphs that I wrote said that even though high fees are an issue, if we removed fees from the equation we would still see that some solutions are much better than others. But your logic is still flawed, if you have features that no one else has, wouldn't you want to crush any competition with lower fees, while finding the balance giving your service the highest rewards?
I don't have to hear complaints from MNOs, most MNs are not running at our minimum recommended specs. How do I know? Because many can barely service mobile clients.
This is not emotional blackmail, I am stating facts, if you choose to ignore them, then you should vote the way of your ignorance.
You're being paranoid, following a hard fork such as the one we've just had, it is fairly typically to see some of the forked off nodes get back on the right chain following their belated upgrades.Just curious about the recent uptick in active masternodes:
Dash Masternode Information
178.254.23.111
If this number continues upwards as we go into voting... is there a possibility of collusion to try and swing votes? I mean to say, can someone at MNOWatch fingerprint recently activated nodes? Maybe I'm just being paranoid.
That said, we are still nowhere near where we ought to be and hopefully we see more nodes come back online soon.
Sure, and let's take the example by Rion where we only reward Platform with 20%. In his example he expects 600 nodes to join.
Okay now we turn on Platform. WeeJohny whale joins with his 220 nodes. Weejohny is running more than 1/3rd of Platform nodes, him stopping his nodes would stop Platform. And he doesn't even have to do this on purpose, he could just join, maybe decide to stop, or even upgrade his nodes all at the same time. Such a solution is not only risky, but it's insane.
So what must we do? We need to reward Platform more, so that there are more nodes, diluting the power of 1 or 2 whales. Okay let's reward 50/50 now. We now have 1800 nodes instead of 600. So safe you say? Maybe... but it's never a good thing to say maybe. The probability that Weejohny can now stop the chain is very low. 3.58 * 10 ^ -9 .
But are we setting our bar so low at 1 MNO? We had been calculating the "safety" of the network as one entity controlling of "power" of 378K Dash. This represents multiple MNOs worth of stake.
Using 378K Dash we get the probability of 0.13% per quorum, or 99%+ per year.
As a reference HPMN 4K is 0.03% per quorum, and HPMN 10K is pretty much 0%.
I am confused here, does Core not have a robust PoSe scoring solution that gives misbehaving masternodes in quorums specific PoSe scores and ultimately PoSe bans if that score gets too high ? Cutting those masternodes off from getting further MN payments ? The PoSe solution on Core was always focused on masternodes, PoSe scoring masternodes, not sure why mobile phones are brought into this. Is there even a need for the PoSe scoring system on Core to service mobile phones with blockchain data ? I would say Core works precisely because of the robust PoSe scoring system banning misbehaving masternodes on the masternode network.
Is that not also what we need for Dash Platform ? A way to PoSe score misbehaving masternodes in Platform quorums, expel them from Platform quorums if necessary and ultimately ban them so they can't receive Platform rewards ? Was this not also originally planned for Dash Platform ?
If we had a PoSe scoring solution active on Platform (if it was given priority years ago), would we even have this discussion about the safety of the Platform on all nodes solution during startup of Dash Platform, right now ?
Would WeeJohny whale still be a threat, if DCG developed a robust PoSe scoring solution for Platform alongside the other essentials for the launch of Dash Platform ? It is easy to talk about a lack of funds, lack of time, lack of manpower now in late 2022, but the PoSe scoring solution for Platform could have been prioritized by DCG years ago and co-developed alongside quorum rotation, drive, fee system, porting Javascript to Rust, re-coding large parts of code (starting all over again from scratch), and all those other essentials that were given priority over the years.
Seeing CTO of DCG so actively promote the 4K / 10K HPM solutions and so actively undermine the Platform on all nodes solution (which on itself is already undermined by a lack of a robust PoSe scoring solution on Platform), gives a sour taste in my mouth.
There is a reason why we are in the situation that we are in right now. There is a reason why we are about to be presented with DCG decision proposals, where none of the DCG decision proposals are really in the best interest of the network (two of the proposals lead to network centralization and one proposal could have a network safety issue).
After having allocated so much funding into Dash Platform and after having waited this many years for the release of Dash Platform, the available options to start Dash Platform, are disappointing to say the least.
Last edited:
Christ, you really are digging your own hole on this one. Not the smartest of admissions. Just how many masternodes are there cheating Core's PoSe?
Am confused what you're saying. You're making the case for a more robust PoSe or a less PoSe on Platform?
What competition? There is no viable alternatives to Platform, right? You said it was a unique and top notch product that "will have many features that no other blockchain will have". This is why you're the technical guy and not the business guy, and quite possibly why you don't care so much for the fiat price of dash at $40. For if you did, there would of been more money in the treasury to hire more people, and more money for 1K MNOs to upgrade.
Sure is blackmail. By putting it to vote now, you are attempting to push some of your responsibility onto MNOs. For if there is a catastrophic bug that takes down the entire network, you will say, "I told you so" even though DCG is the architect and the builder. Doesn't have faith in his own product so pushes through this 4K / 10K kludge. If the software is that unstable then maybe you shouldn't launch it at all.
If we jump straight to 4K / 10K HPMNs, we will bypass the evidence that a 1K Platform will find an audience, or not. Until it is live and running for a while, we can not be certain of our users and developers needs. How can we find the Goldilocks principle if you first steal one of the bowls?
In 1999 Shazam launched the first application to fingerprint and identify music. Initially, it was available to everyone via a phone call and then later an app. It took 17 YEARS for them to turn a profit and the real money was not made from their initial target audience but through royalty collections. Dash Platform is in this same position, a unique product that has yet to find it's niche... but you sure are hell bent on limiting the options now instead of later.
Shazam (application) - Wikipedia
en.wikipedia.org
Last edited:
Can you help us understand what it means to stop platform? What are the details? Does it require manual intervention from MNOs to reset MNs? How long would a disruption last.
The fact that you say that I'm undermining the "All nodes run platform" solution, makes me understand that you question my facts. I am trying my best to give facts, and then give my advice.
No blockchain project that I know verifies that nodes are serving queries. As an analogy I might be saying "We don't have a fusion reactor for our trip to Mars". And you seem shocked by this fact. What we do have in core is a proof of participation in quorums. This is more than good enough for Core because the core chain proceeds with Proof of Work. But Platform is Proof of Stake, and is actually a special type of proof of stake called Scalable Byzantine Fault Tolerance. This technology has very great upsides but different requirements, as the chain would stop if enough nodes stop servicing.
I'm not really sure what you want to get at, or what you are trying to achieve. Even with a perfect PoSe system we would still get into many of the outlined issues, as Proof of Service only really changes the carrot into a stick. Meaning that rewards would stay the same, you just would get punished for not serving the network instead of rewarded for serving the network. I'm pretty sure that if we had done this probably more people would have been unhappy, plus it's a lot harder.
I get it, you don't like the 4K/10K systems. Propose what you do prefer. Each solution has benefits and drawbacks, we are trying our best to be honest and convey the pros and cons of each to the network.
Yes, if platform stopped it would require all the network to upgrade to a new version. I am not sure how long the disruption would last, but I could imagine a few days to a week.
At this point, after having heard the benefits and drawbacks of all three solutions and after the revelation of the safety risk on the Platform on all nodes solution (Platform down, all masternodes down), i don't think there are any good options to choose. It is just a choice between bad options at the moment.
I even wonder why Tendermint was used / forked in the first place, with this flaw of PoS blockchains known to devs. This was bound from the start to give problems with implementing Platform on all masternodes. And i still find it weird that we only find out about it, during the very last phase of development before release.
And lets not forget about Dash Original Vision and Dash Platform Vision as communicated to us in the DCG Quarterly Call Q4-2021 :
Source : https://www.dash.org/forum/threads/...terly-call-3-february-2022.52664/#post-229650
The term 'Decentralized' is heavily emphasized in both Dash Original Vision and Dash Platform Vision. And there is even a specific mention of State information to be distributed amongst all nodes.
The 4K HPM and 10K HPM decision proposals that DCG is planning to introduce are heavily interfering with at least the Dash Platform Vision.
Last edited:
To me decentralization means the power is the most spread out.
46% of Ethereum validators are owned by 2 operators. There are thousands upon thousands of validators though. Are they more or less decentralized than the HPMN solution?
46% of Ethereum validators are owned by 2 operators. There are thousands upon thousands of validators though. Are they more or less decentralized than the HPMN solution?
What has stood out to me most in this discussion is the comment section on DCG's most recent funding proposal. In it is discussed the possibility of masternodes/supermasternodes having the ability to select which kinds of Platform content they will and will not host.
This was my first time hearing about this, and I'm confused. How would the super/masternodes even know what particular content they are hosting? And provided they had this knowledge, how would they actually go about kicking data off their node?
This was my first time hearing about this, and I'm confused. How would the super/masternodes even know what particular content they are hosting? And provided they had this knowledge, how would they actually go about kicking data off their node?
Timelocks adhere to your keys your coins. You would not be giving away any of your keys or coins. A timelock simply restricts the spending of the collateral until a specified future time or block height.
I agree with what @dashfriend_ said about keys. As for this:
How do 4k or 10k nodes fix this in a way that locked 1k nodes don't?
Won't be long before the dolphin MNOs put dash in the exact same position as ethereum. It seems DCG is so focused on integrating this PoS altcoin called Platform, that DCG hasn't even recognized the problem, let alone try to fix it.
At this point i as a masternode owner wonder if the Dash Trust Protectors should be involved or not.
* DCG is preparing changes that directly violate its publicly communicated Dash Platform Vision to the Dash community (keeping Dash Platform decentralized)
See : https://www.dash.org/forum/threads/...h-performance-nodes.53374/page-12#post-232556
* DCG wants to introduce these changes through three separate DCG decision proposals, which all three do not serve the best interest of the network (two decision proposals centralize Dash Platform in direct violation of its own Dash Platform Vision, one decision proposal has an inherent safety issue which makes this solution effectively a no-option).
DCG wants to use the outcome of these three DCG decision proposals (highest number of yes votes) to determine its direction on how to start Dash Platform. But by only providing those three options to vote on (Platform on all masternodes decision proposal with its safety issue and the two high performance decision proposals that violate its own Dash Platform Vision with regards to decentralization), DCG has limited the options for masternode owners on how to proceed with Dash Platform and publicly demonstrated to the Dash community, that DCG is currently not acting in the best interest of the network.
Can someone else introduce a decision proposal that offers an alternative solution or offers a delay of Dash Platform ? Sure.
But that does not absolve DCG from currently not acting in the best interest of the network, by planning to introduce only these three specific decision proposals and showing no intention to change course.
* DCG is preparing changes that directly violate its publicly communicated Dash Platform Vision to the Dash community (keeping Dash Platform decentralized)
See : https://www.dash.org/forum/threads/...h-performance-nodes.53374/page-12#post-232556
* DCG wants to introduce these changes through three separate DCG decision proposals, which all three do not serve the best interest of the network (two decision proposals centralize Dash Platform in direct violation of its own Dash Platform Vision, one decision proposal has an inherent safety issue which makes this solution effectively a no-option).
DCG wants to use the outcome of these three DCG decision proposals (highest number of yes votes) to determine its direction on how to start Dash Platform. But by only providing those three options to vote on (Platform on all masternodes decision proposal with its safety issue and the two high performance decision proposals that violate its own Dash Platform Vision with regards to decentralization), DCG has limited the options for masternode owners on how to proceed with Dash Platform and publicly demonstrated to the Dash community, that DCG is currently not acting in the best interest of the network.
Can someone else introduce a decision proposal that offers an alternative solution or offers a delay of Dash Platform ? Sure.
But that does not absolve DCG from currently not acting in the best interest of the network, by planning to introduce only these three specific decision proposals and showing no intention to change course.
Last edited: