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

[GrandMasterDash]

Here is a modification of DCGs proposal:

First, we reduce the masternode collateral to 500 dash.

Then, instead of using collateral for HPMNs, we use Liquidity Pools. If a masternode wants to participate in Platform, they register their node and create something similar to a Lightning channel. At this point, anyone can add to the channel until a minimum of 5000 dash is raised. You will note, this is the same setup as a 10K HPMN. You will also note, this is not the same as shared masternodes as there are no penalties or consequences for adding and removing shares. The goal is simply to reach the 5K threshold by any means possible.

From the grand total of all channels, 50% is allocated to the donors and the remaining 50% goes to participating masternodes.

The masternode network can enforce a minimum donation of 10 dash, this is to limit spam payments clogging up payouts. To ensure enough masternodes exist, the network can also enforce a maximum of 5.1K dash.

--------

I'm not sold on HPMNs, I just wanted to improve on the original proposal.

In an ideal world, HPMNs would not be more than 1K dash, but if they must be, then I prefer this method.

 

[DASHvestor]

Funny how this is all coming out only now.
Never during the 7 year long journey of Platform development, has the MNO network been asked or polled on directions by the devs, after explaining the various tradeoffs.

If its true that Platform will not waste resources (i really doubt it), it could as well run on all 1K nodes, according to what was the original Platform/Evo Vision.
But now they claim, all 1K nodes running Platform would somehow slow it down or make Platform lame.
Then this is a serious coding/development shortcoming you should try to overcome and fix, rather than trying to adjust the whole network to your coding deficiencies.

More Platform Nodes (= More Decentralization) and that must never (!) be a bad thing. Otherwise, once Decentralization becomes bad, something is very wrong.
The devs could as well think about a solution which is not burdened by a greater amount of Platform Nodes (all 1K Nodes), to the contrary, a greater amount of Platform Nodes should be something useful and ideally decrease the hardware needs for every single Platform Node.

I understand that for you devs 4K or 10K is the overall easy fix, even if it complicates a couple of other aspects.
But easy is not always the best.

 

[GrandMasterDash]

I've just had a brainwave and would like to add to my previous idea of LPs on a Lightning style channel:

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

Here is a modification of DCGs proposal: First, we reduce the masternode collateral to 500 dash. Then, instead of using collateral for HPMNs, we use Liquidity Pools. If a masternode wants to participate in Platform, they register their node and create something similar to a Lightning channel...

www.dash.org

The masternode network could regularly mix coins on LPs that collateralize the HPMNs and then when a user wants these mixed coins, their funds are simply swapped with the LP. No more waiting hours to mix coins!

 

[qwizzie]

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)

View attachment 11467

Why?

2. This solution satisfies the main stated goals of the "high performance masternode" proposal:

- It can mitigate the risk of multiple platform nodes dropping off with staggered time locks.

- It can mitigate the risk of multiple platform nodes dropping off with staggered time locks.

Is this to be considered a temporary fix to the risk of multiple platform nodes dropping off, untill DCG comes up with a definitive solution ?
Or do staggered time locks provide a longterm fix to the risk of multiple platform nodes dropping off, even after the timelocks unlock ? (lets say for example the time locks unlock after 1 year)

What i am wondering about is if we still have this problem (the risk of multiple platform nodes dropping off), after that timelock expires in a year or after six months.
Is it a case of buying devs some time to implement something more permanently ?

 

[rion]

Is this to be considered a temporary fix to the risk of multiple platform nodes dropping off, untill DCG comes up with a definitive solution ?
Or do staggered time locks provide a longterm fix to the risk of multiple platform nodes dropping off, even after the timelocks unlock ? (lets say for example the time locks unlock after 1 year)

It's not a fix in the sense that it guarantees no risk (it just mitigates, not eliminates). The degree of mitigation would depend on the implementation.

My original thought with timelocks is simply that whales (especially 3rd party custodians) would not want to lock up all their nodes at the same time (regardless of timelock duration). Imagine you have 100 nodes, would you want to lock every single one up at the same time? Unlikely, because a) then you then have zero liquidity, and b) you don't want to get into a situation where your platform masternodes are less profitable, for whatever reason, than your normal masternodes (or other non-Dash alternatives for that matter). You might lock only 25% or 50% of your nodes, and/or stagger them over a time period. For example you might spin up 10 now, 10 more in a week, another 10 in another week, and so on until you're satisfied that you have a stable, relatively liquid investment that is more profitable than your alternatives.

The point is, with timelocks, it's very unlikely that you'll ape in with all your nodes at the same time. If that's the case, then there's much less of a risk to the platform that huge amounts of nodes by one entity will suddenly drop off, or be upgraded at the same time. That's the main risk as I understand it, so, problem significantly mitigated.

I imagine under timelocks that we'd see a relatively slow, smooth influx of small amounts of nodes from dedicated operators at first. They would be handsomely rewarded for being the first in (and you don't have to be a quadra- or deca-whale to have this opportunity - just need to be dedicated to holding Dash). Because there's a higher barrier to entry you won't see a mad rush of operators switching over their whole fleets on day one, which is exactly what you want.

So I think it both buys devs more time (without a drastic and hasty collateral increase) and, depending on what we see in terms of which nodes decide to run platform, it may even offer a permanent solution with even a one-time timelock. The timelock requirement could potentially even be removed in the future if we see a well-distributed mix of operators (no 130+ node operators, for example).

 

[GrandMasterDash]

@rion Actually, you see this in decred, the price doesn't react so quickly to market changes because so much is locked up. I would still prefer 1K HPMNs though.

 

[rion]

@rion Actually, you see this in decred, the price doesn't react so quickly to market changes because so much is locked up. I would still prefer 1K HPMNs though.

Yeah, price dampening is a nice side benefit.

I'm not sure what you meant.by "I would still prefer 1K HPMNs though". Keeping all masternodes at 1,000 DASH is what I'm proposing.

 

[GrandMasterDash]

Yeah, price dampening is a nice side benefit.

I'm not sure what you meant.by "I would still prefer 1K HPMNs though". Keeping all masternodes at 1,000 DASH is what I'm proposing.

Get some rest, you know what I meant

 

[vampyren]

Funny how this is all coming out only now.
Never during the 7 year long journey of Platform development, has the MNO network been asked or polled on directions by the devs, after explaining the various tradeoffs.

If its true that Platform will not waste resources (i really doubt it), it could as well run on all 1K nodes, according to what was the original Platform/Evo Vision.
But now they claim, all 1K nodes running Platform would somehow slow it down or make Platform lame.
Then this is a serious coding/development shortcoming you should try to overcome and fix, rather than trying to adjust the whole network to your coding deficiencies.

More Platform Nodes (= More Decentralization) and that must never (!) be a bad thing. Otherwise, once Decentralization becomes bad, something is very wrong.
The devs could as well think about a solution which is not burdened by a greater amount of Platform Nodes (all 1K Nodes), to the contrary, a greater amount of Platform Nodes should be something useful and ideally decrease the hardware needs for every single Platform Node.

I understand that for you devs 4K or 10K is the overall easy fix, even if it complicates a couple of other aspects.
But easy is not always the best.

Agree on this!

I would say having 1000 Dash collateral should not be changed as this is the base principal of MN network.
The for HPMN, maybe have this as optional with more incentive so people who like to run HPMN can do it and the ones who dont want an secure the network as they are today. This incentive is also partially and indirectly coming from data storage fee as i understand it...

 

[rion]

for HPMN, maybe have this as optional with more incentive so people who like to run HPMN can do it and the ones who dont want an secure the network as they are today.

Are you using “HPMN” (high performance masternode) as synonymous with high collateral masternode?

“High performance masternode” is a misnomer. I’ve heard no evidence or even theory why high collateral nodes would be more “performant” than a 1,000 DASH collateralized node. In practice nodes will generally only be as performant as needed to get paid, and this has nothing to do with the collateral backing them.

I suppose Sam likes the “HPMN” term because it helps sell his idea. Until @QuantumExplorer can show that there is an identifiable link between performance and collateral I consider this naming practice no better than politicians who name bills for marketing purposes rather than descriptive purposes, just to gain popularity - it’s a shameful practice.

Please, everyone, stop calling them high performance masternodes. Call them high collateral masternodes (HCMNs) if you want. I prefer the more descriptive and neutral “platform (master)nodes”.

With that out of the way, i like the idea of making high collateral optional. We discussed this very thing on a call a while ago. The idea would be to let operators choose a higher collateral to back a node, so for example instead of running two 1,000 DASH-backed nodes, you could run one 2,000 DASH-backed node. The latter would get paid the same as the former, but would have lower operating costs. That would incentivize multi-node operators to run fewer nodes, which Could be better for the network. It’s definitely something to consider and research more. I’m guessing DCG has thought of it, but I haven’t heard anything about it.

 

[AgnewPickens]

Are you using “HPMN” (high performance masternode) as synonymous with high collateral masternode?

“High performance masternode” is a misnomer. I’ve heard no evidence or even theory why high collateral nodes would be more “performant” than a 1,000 DASH collateralized node. In practice nodes will generally only be as performant as needed to get paid, and this has nothing to do with the collateral backing them.

I suppose Sam likes the “HPMN” term because it helps sell his idea. Until @QuantumExplorer can show that there is an identifiable link between performance and collateral I consider this naming practice no better than politicians who name bills for marketing purposes rather than descriptive purposes, just to gain popularity - it’s a shameful practice.

Please, everyone, stop calling them high performance masternodes. Call them high collateral masternodes (HCMNs) if you want. I prefer the more descriptive and neutral “platform (master)nodes”.

With that out of the way, i like the idea of making high collateral optional. We discussed this very thing on a call a while ago. The idea would be to let operators choose a higher collateral to back a node, so for example instead of running two 1,000 DASH-backed nodes, you could run one 2,000 DASH-backed node. The latter would get paid the same as the former, but would have lower operating costs. That would incentivize multi-node operators to run fewer nodes, which Could be better for the network. It’s definitely something to consider and research more. I’m guessing DCG has thought of it, but I haven’t heard anything about it.

With no POSE system in place for Platform, it is disingenuous to call Platforms nodes "High Performance" - there is no compliance
system in place for using sufficient hardware.

 

[GrandMasterDash]

While we're at it, might as well change "master" because I'm not sure who or what the slave is

These new higher collateral nodes will likely lead to their owners achieving more community influence. Do I get to upgrade my forum badge accordingly? Also, can someone update my forum badge to commemorate my presence here for 7+ years? haha

 

[vampyren]

Are you using “HPMN” (high performance masternode) as synonymous with high collateral masternode?

“High performance masternode” is a misnomer. I’ve heard no evidence or even theory why high collateral nodes would be more “performant” than a 1,000 DASH collateralized node. In practice nodes will generally only be as performant as needed to get paid, and this has nothing to do with the collateral backing them.

I suppose Sam likes the “HPMN” term because it helps sell his idea. Until @QuantumExplorer can show that there is an identifiable link between performance and collateral I consider this naming practice no better than politicians who name bills for marketing purposes rather than descriptive purposes, just to gain popularity - it’s a shameful practice.

Please, everyone, stop calling them high performance masternodes. Call them high collateral masternodes (HCMNs) if you want. I prefer the more descriptive and neutral “platform (master)nodes”.

With that out of the way, i like the idea of making high collateral optional. We discussed this very thing on a call a while ago. The idea would be to let operators choose a higher collateral to back a node, so for example instead of running two 1,000 DASH-backed nodes, you could run one 2,000 DASH-backed node. The latter would get paid the same as the former, but would have lower operating costs. That would incentivize multi-node operators to run fewer nodes, which Could be better for the network. It’s definitely something to consider and research more. I’m guessing DCG has thought of it, but I haven’t heard anything about it.

Thank you for clarifying that! And your assumption was correct. I cant say 100% where but i have in the back of head that it was mentioned the need for running platform will/should be higher but can't remember if it was youtube video or in Discord or forum i read/heard it. But great to have this in the clear.
And to be honest i would not mind to have the HCMN having better hardware if that is what is required. My only beef with 4k/10k etc is that it will divide the community more than anything. To much hurdle to list really but several on the the thread already so i'm sure you know what they are
And if DCG has thought about them they sure keep quiet. I feel sometime we dont get the why's only the how's during their presentation.

 

[rion]

I cant say 100% where but i have in the back of head that it was mentioned the need for running platform will/should be higher

Yes, platform nodes will have higher performance requirements. My point was just that having a higher collateral has nothing to do with node performance. You can get higher performing nodes with any collateral (1k, 4k, 10k, etc).

My only beef with 4k/10k etc is that it will divide the community more than anything.

Yes, that's why I'm going through the trouble of proposing an alternative that gives us high enough security and low enough costs, but without increasing collateral for platform nodes.

 

[tyyler]

I am leaning against the High Performance Masternode Solution because of :

Data replication would get a lot more centralized over less nodes. This undermines the availability of data stored on the masternode network / Dash Drive and could by itself form a single point of attack / single point of failure in the future. What if an entity decides to DDoS those select few 100 of High Performance Masternodes ? It is much more difficult to (sybil?) attack 4000 masternodes, then (sybil?) attack 100 High Performance masternodes. Not to mention possible problems during large software updates, where masternode numbers in general drop like flies, because masternode operators don't keep up with Dash updates or run into problems. If you ask me the above picture with the two described solutions is not a choice between more decentralized and less decentralized, but a choice between more decentralized and more centralized (no point avoiding the c word here).

Current Masternode Whales (those with 5 or 10 or more masternodes) would have no problem setting up a High Performance Masternode or two, but everyone else with less then 5 masternodes or less then 10 masternodes (depending on the outcome of the collateral discussion for High Performance Masternodes) would be denied setting up a High Performance Masternode. In my eyes this could seriously undermine the trust of the Dash community / current masternode operators in Dash Platform, as it radically changes the requirements of running a masternode on Dash Platform. Yes people can now choose to not run a masternode on Dash Platform, but at the same time you deny a lot of people that want to run a masternode on Dash Platform that option. And lets not forget that there could be additional revenue streams in the future for those masternodes that participate on Dash Platform. Those revenue streams should be available to all masternodes in my view, not to a select few 100 masternodes.

Also the centralization aspect of the High Performance Masternode Solution opens Dash up to attacks from Dash competitors, claiming Dash itself to be centralized. It will be difficult to defend Dash from that, because there is truth in it.

So at this point i am favoring the Masternode Solution, where Dash Platform is run on all nodes and way more decentralized.

I agree with you 100%

 

[qwizzie]

I agree with you 100%

Unfortunately some safety issues with the Platform on all nodes arised later in this discussion thread, that were never publicly disclosed to the Dash community before and in the many years of Platform development were never addressed or prioritized by Platform developers, which currently handicaps the Platform on all nodes solution. Some can be mitigated by a Proof of Service (PoSe) for Dash Platform, some need a different solution.

So personally i am having difficulty with any of the upcoming DCG decision proposals (4K HPM, 10K HPM, Platform on all nodes) and i am currently looking into alternative solutions, like Rion's solution.

It is unfortunate that we find ourself in this situation now, where pretty much all available start options (excluding Platform on all nodes, but this start option has its own very specific safety issues) lead to Platform network centralization. With some leading to more Platform network centralization (and more risk to censorship), then others.

10K HPM : Estimated 180 Platform masternodes according DCG Presentation. I checked today on mnowatch.org the estimate lead to 159 Platform masternodes (see my next post).

This also has the risk of possible future censorship, as the top 7 masternode whales have a 60% Platform masternodes majority in that 10K HPM solution and if DCG decides that only Platform masternodes get to vote on what types of content can be stored on Platform, those top 7 masternode whales ultimately get to dictate (through Platform voting) what kind of content is allowed on Platform and what kind of content is not allowed on Platform.

4K HPM : Estimated 450 Platform masternodes according DCG Presentation. I checked today on mnowatch.org the estimate lead to 430 Platform masternodes (see my next post).

This also has the risk of possible future censorship, as the top 7 masternode whales have a 60% Platform masternodes majority in that 4K HPM solution and if DCG decides that only Platform masternodes get to vote on what types of content can be stored on Platform, those top 7 masternode whales ultimately get to dictate (through Platform voting) what kind of content is allowed on Platform and what kind of content is not allowed on Platform.

Rion : Estimated 600 Platform masternodes according his post (https://www.dash.org/forum/threads/...h-performance-nodes.53374/page-12#post-232537), but that could be subject to change.

If any of above start options passes, the future revenue streams from Platform (either through increased Platform usage or through dapps providing additional revenue streams in the future), will be limited to those specific small Platform masternode groups.

 

[GrandMasterDash]

What happens if a masternode humpback service such as Binance or Crowdnode opens up to HPMNs and ALL their customers choose to have their shares completely in HPMNs i.e. too many HPMNs and not enough MNs? When the end customer has no actual stake they will make irrational decisions and the Humpback services can not breach what the customer expects. Isn't this also a security risk?

 

[qwizzie]

I ran the calculations on the data from mnowatch.org just now and came with the following numbers for masternode whale node estimates for 10K and 4K

Source : https://mnowatch.org/Types/index.html?1=

For 10K the estimated total number of Platform masternodes currently comes at 159 and 60% majority is currently at 95.4 / 7 Whales (101)
For 4K the estimated total number of Platform masternodes currently comes at 430 and the 60% majority is currently at 258 / 7 Whales (260)

Not so long ago (30th of october 2022) it could take 5 whales to reach a 60% majority, now it requires 7 whales. So the situation and the estimated numbers are fluid, not fixed. Most likely due to smaller masternode whales buying more dash and setting up more masternodes, as the numbers of the top 5 masternode whales have not changed that much. Also Masternode whale 'Tantalum' seems to be a new rising top masternode whale spotted by mnowatch.org, since very recent (8th of Nov 2022).

Crowdnode does not seem to have much of an impact so far on above estimates.
Binance needs to have a lot of operational liquidity in dash for their exchange, so i don't think they will drastically increase the number of masternodes from their large stash of dash any time soon.

 

[rion]

What happens if a masternode humpback service such as Binance or Crowdnode opens up to HPMNs and ALL their customers choose to have their shares completely in HPMNs i.e. too many HPMNs and not enough MNs? When the end customer has no actual stake they will make irrational decisions and the Humpback services can not breach what the customer expects. Isn't this also a security risk?

it's pretty unlikely that there will be "too many HPMNs platform nodes and not enough MNs" if the allocation is thought out well. The roughly 650 nodes my model predicts is based on a 20% allocation. DCG's proposals all allocate 50% to platform nodes. Either way, you're not going to have a situation where the platform node yield is much lower (if at all) than normal masternode yield. At least not if we're considering just the basic economic incentives.

 

[GrandMasterDash]

it's pretty unlikely that there will be "too many HPMNs platform nodes and not enough MNs" if the allocation is thought out well. The roughly 650 nodes my model predicts is based on a 20% allocation. DCG's proposals all allocate 50% to platform nodes. Either way, you're not going to have a situation where the platform node yield is much lower (if at all) than normal masternode yield. At least not if we're considering just the basic economic incentives.

This is assuming yield is always the deciding factor or that the humpback operators will not lie to their customers about allocation. For example, if there's an important proposal (and self-published?), the humpback may decide the best incentive is voting power and simply pay off the difference. In essence, there is NOTHING at the protocol level to enforce how the humpbacks behave. Until this is fixed, dash governance and the entire treasury is at substantial risk.

 

[rion]

For 10K the estimated total number of Platform masternodes currently comes at 159 and 60% majority is currently at 95.4 / 7 Whales (101)
For 4K the estimated total number of Platform masternodes currently comes at 430 and the 60% majority is currently at 258 / 7 Whales (260)

Just an FYI, DCG and I are both assuming there is risk when any single entity controls 33%+ of a quorum. At 60% (or is it 66%) there is risk of more serious problems (like funds at risk). According to the statistical calculations being able to control 33% of a 100-node quorum starts happening when 1 (or more if you're accounting for collusion) entity controls around 20% of the platform nodes.

 

[rion]

This is assuming yield is always the deciding factor or that the humpback operators will not lie to their customers about allocation. For example, if there's an important proposal (and self-published?), the humpback may decide the best incentive is voting power and simply pay off the difference. In essence, there is NOTHING at the protocol level to enforce how the humpbacks behave. Until this is fixed, dash governance and the entire treasury is at substantial risk.

Right. That's why I said "At least not if we're considering just the basic economic incentives."

If we're considering scenarios where 3rd party custodian humpbacks (like Binance) are lying to their customers, propping up yield from non-native sources, and in general acting maliciously then all (or at least most) bets are off with platform security.

That's actually exactly why I'm proposing time locks, so that potentially malicious 3rd party custodians are more hindered in converting significant amounts of their nodes to platform nodes.

 

[GrandMasterDash]

Perhaps better to ask, what are the odds of collusion? I've been trying to highlight this risk for ages, let alone with an elite group of HPMNs.

I am not voting Yes on any proposal requiring more than 1000 dash. We will have more benefit from reducing current masternode requirements, decentralize the network further. And no, not all MNOs would switch to running more nodes, some have bills to pay / more desperate and would welcome the option to sell some dash yet retain a masternode.

 

[GrandMasterDash]

Right. That's why I said "At least not if we're considering just the basic economic incentives."

If we're considering scenarios where 3rd party custodian humpbacks (like Binance) are lying to their customers, propping up yield from non-native sources, and in general acting maliciously then all (or at least most) bets are off with platform security.

That's actually exactly why I'm proposing time locks, so that potentially malicious 3rd party custodians are more hindered in converting significant amounts of their nodes to platform nodes.

Yes, and I am glad this is recognized, especially in light of recent events.

 

[GrandMasterDash]

Can someone please tell me what is wrong with my idea for crowdfunded LPs operating like a Lightning Network? I genuinely want to know, see here....

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

Here is a modification of DCGs proposal: First, we reduce the masternode collateral to 500 dash. Then, instead of using collateral for HPMNs, we use Liquidity Pools. If a masternode wants to participate in Platform, they register their node and create something similar to a Lightning channel...

www.dash.org

 

[qwizzie]

Just an FYI, DCG and I are both assuming there is risk when any single entity controls 33%+ of a quorum. At 60% (or is it 66%) there is risk of more serious problems (like funds at risk). According to the statistical calculations being able to control 33% of a 100-node quorum starts happening when 1 (or more if you're accounting for collusion) entity controls around 20% of the platform nodes.

I am using the 60% majority to show whales concentration in the specific case only Platform nodes get to vote in the nearby future on what types of content can be stored on Platform. So basically it is a 60% voting majority (currently 7 masternode whales), that have enough nodes / possible voting power, to make future Platform proposals on Platform content pass. It is not related to quorums, but it is related to how DCG plans to deal with future content storage on Platform (which by the way requires a Platform PoSe). Details about how DCG plans to deal with future content storage on Platform can be found here here : https://www.dash.org/forum/threads/...h-performance-nodes.53374/page-18#post-232783

quote from Sam:

+

The smaller the Platform group nodes (4K HPM / 10K HPM), the more centralized the future voting power on Platform content by Platform nodes becomes (if only Platform nodes get to vote on what types of content can be stored on Platform), together with an increased risk of possible censorship on future Platform content storage.

 

[qwizzie]

Can someone please tell me what is wrong with my idea for crowdfunded LPs operating like a Lightning Network? I genuinely want to know, see here....

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

Here is a modification of DCGs proposal: First, we reduce the masternode collateral to 500 dash. Then, instead of using collateral for HPMNs, we use Liquidity Pools. If a masternode wants to participate in Platform, they register their node and create something similar to a Lightning channel...

www.dash.org

Maybe you can also create a separate discussion topic about this in the General Discussion section, just like krilen did with his Distributed Platform Storage concept idea ? This would increase visibility to your concept idea and have less risk of it getting drowned in this thread.

I have no experience with Lightning channels or Liquidity Pools, so i have difficulty visualizing the concept to be honest. Reducing the collateral to 500 dash would most likely trigger current masternode whales to just setup twice as many masternodes. I am not sure how it would entice those current masternode whales to join a liquidity pool, instead of just setting up another masternode... unless the idea is to have both ? Have more masternodes and have liquidity pools ?

Also with setting up another masternode, you are pretty guaranteed of your additional revenue. Is the same with liquidity pools or is there a build-up phase untill you start receiving revenue (first gather 5000 dash, then receive LP revenue ?)

 

[TheNetworkIsBiggerThanYou]

View attachment 11403

Source : www.youtube.com/watch?v=EMmvP6G3NrE
Timestamp 52:30

Please take the time to fully watch the discussion of this topic by Dash Platform team during their Dash Platform Product Update S91 (see above source link and timestamp).

For the High Performance Masternode Solution there is talk of raising the Dash collateral to either 10.000 dash (higher TPS but more centralized) or 5.000 dash (less TPS but a bit more decentralized, but nowhere near as decentralized as having Dash Platform run on all nodes ofc).

Nothing is finalized, everything is still very much in flux. The Dash Platform team indicated feedback from the Dash community would be helpfull, so that is why i am kickstarting the discussion here.

Update 7th of October 2022 :

DCG : Introductory presentation on High Performance Masternodes
Link : www.youtube.com/watch?v=oQ0iJZ1pvsc

it would be better instead of saying more or less decentralized in a chart, what it means. It seems the less decentralized option actually means easily censorable/ designed to be censored.

 

[AgnewPickens]

Hear me out, 1337 nodes, collateral fixed, but not rounded, I wrote all this out earlier, this makes it hard for whale accounting,
Does not raise collateral signficantly but keeps all the Platform nodes identical in collateral which apparently is required for
threshold sigs. Also, 1 Platform node gets 1 vote like 1 core node, but core rewards are weighted to 1.337.

 

[qwizzie]

With that out of the way, i like the idea of making high collateral optional. We discussed this very thing on a call a while ago. The idea would be to let operators choose a higher collateral to back a node, so for example instead of running two 1,000 DASH-backed nodes, you could run one 2,000 DASH-backed node. The latter would get paid the same as the former, but would have lower operating costs. That would incentivize multi-node operators to run fewer nodes, which Could be better for the network. It’s definitely something to consider and research more. I’m guessing DCG has thought of it, but I haven’t heard anything about it.

With regards to lower operating costs :

two 1,000 DASH-backed nodes

1x server
2x 1000 dash collateral
2x dedicated IP addresses
2x RAM usage for dashd processes
2x SDD storage for full Dash blockchains

Server costs : renting 1 VPS server, having 1 dedicated ip address + renting 1 additional dedicated ip address, picking RAM & SSD that has required RAM amount & SSD storage for running 2 masternodes

Receiving 2x 1,44 dash per 7 days

one 2,000 DASH-backed node

1x server
1x 2000 dash collateral
1x dedicated IP address
1x RAM usage for dashd process
1x SSD storage for full Dash blockchain

Server costs : renting 1 VPS server, having 1 dedicated ip address, picking RAM & SSD that has required RAM amount & SSD storage for running 1 masternode

Receiving 2x 1,44 dash per 7 days

The lower operating costs is mostly in being able to rent a VPS with a lower price tier plan, with less RAM and less SSD storage.
Correct ? Or am i looking at this the wrong way ?

I am mentioning this because i suspect most masternode owners with multiple masternodes (4 or 5), will most likely just have 1 VPS server with a bunch of additional ip addresses (renting 1 additional ip address is just a few dollars / euro's per month). And with options to increase CPU core numbers, RAM amount, and SSD storage amount, by moving to a higher price tier. I don't think they actually rent several separate VPS servers.

Note : not all VPS providers allow people to downgrade to a lower price tier. Could lead to a situation of people having to cancel their current VPS setup and starting a new VPS with lower hardware / tier

On a slightly different (but related) topic :

Same goes for 4K Platform nodes and maybe even 10K Platform nodes, those could also be running on the same VPS server. The lower VPS renting costs that Sam mentioned with 4K Platform nodes & 10K Platform nodes, is then basically selecting a lower price tier on their already rented VPS server and cutting back on rented ip addresses. Same goes for big masternode whales running a lot of masternodes that require a few separate VPS servers with a lot of maxed-out additional ip addresses, they also can then just select a lower price tier on those rented VPS's and cut back on rented ip addresses.

Note : the downgrade depends on what they currently have running with regards to CPU, RAM and SSD requiments and what Platform ultimately requires them to run with.