Possible security threat to the Dash Masternode network

[DeepBlue]

This post will present a potential security issue with the Masternode network which arises out of natural market forces acting on Masternode hosting companies. At the end of the post there are some suggestions to mitigate the risks by using a Masternode Hosting Software License.

Hosting a Masternode is a problem for non technical people
Setting up a Dash Masternode requires a reasonable level of technical ability and a lot of patience. Therefore for the non technical person who wishes to host a MN the only viable option is to use a MN hosting company. These MN hosting companies automate the process of setting up a MN and make it possible for anyone to set up a node. Before these hosting companies existed there was no option but to set up a node single handedly which ensured a reasonable level of decentralisation and no single point of failure.

However, with the advent of the MN hosting companies, this has radically reduced the amount of decentralisation of the Dash MN network. And, as you will see later on in this post, this number is actually more likely to be closer to only one or two companies for hosting the majority of the MN network.

Competition and market forces will create the security risk

The link below is to a page on dash.org that list only six MN hosting companies available for Dash:

https://docs.dash.org/en/stable/masternodes/hosting.html

If we look at this list we can see a wide variety of prices for these hosting services from Node40 which is currently 0.6 Dash per month = $62 USD / month to as little as only $5/ month with Allnodes

Node40 pricing at time of writing: $62 USD / Month / Node
https://www.node40.com/hosting/pricing/

Allnodes pricing at time of writing: $5 USD / Month / Node
https://www.allnodes.com/pricing

When comparing Allnodes to Node40 with respect to hosting there does not appear to be that much difference between the two services. Both provide a control panel, both make it simple to set up a node, both have a solid up time record, and both offer tech support. Therefore the question arises why pay $62 / month when a MN owner can pay just $5 / month for a very similar service? If companies like Allnodes demonstrate a solid up time experience then why would a MN owner want to pay anything more than the $5/month with another company?

Market forces over time will lead to MNOs migrating to the cheapest quality hosting service.

However this is where the security issue arises in my opinion. If an ultra competitive hosting company gains more than 51% of the Dash MN this could create a security threat to the network if they were hacked. If their service is excellent it is possible for much more than 51% of the network to be hosted by just one company. A competitive hosting service therefore presents a potential security risk, in my opinion, because the Dash MN network security will only be as good as the security standards implemented by the hosting company. Even if the hosting company acted to the highest possible security standards it still presents a security risk as a single point of failure.

We have seen many cases of exchanges being hacked and millions stolen. A recent example of a lapse in security has been seen with Binance, where allegedly, a Binance insider created a backdoor for a hacker to steal KYC information of 60,000 Binance customers according to the article available on the link below published by Coindesk:

https://www.coindesk.com/a-bitcoin-...ide-binances-negotiations-with-its-kyc-hacker

Exchanges such as Binance have whole departments dedicated to security. Could a MN hosting company even come close to the level of security implemented by an exchange?

An ultra low-cost hosting company could out-compete other hosting companies and we could see the majority of MNs migrating to that host. Do we know for certain if this has already happened? This could form a single point of attack to the Dash MN network.

Which is more probable for an attack: buy 51% of the Dash Masternode network or hack one MN hosting company with more than 51% of the hosted MNs?

With a single tier network an attack would have to come from purchasing mining hardware which is a barrier of cost. With the MN network the security comes from having to buy 1000 DASH to get a Masternode. However if a hacker could hack a DMN hosting company that hosts the majority of the Dash MNs they don't need to buy any Dash. They just need to hack one major Dash MN hosting company that hosts the majority of the MNs to have a potentially catastrophically damaging effect.

The importance of the Dash Masternode Network

The main USP (unique selling proposition) of DASH is the Dash Masternode network. PrivateSend, InstantSend, now with InstantResend, and Chainlocks all rely on the MN network. In addition Dash Evolution will also depend on the MN network for data storage for the new Dash Drive and Dash Accounts. This means that if a hacking event on one of the main hosting companies was to occur it could take down the MN network which could cause catastrophic damage to DASH as a whole.

We could, however, consider implementing procedures to ensure the Dash MN network remains secured and preferably secured through decentralisation.

Some ideas on how to better secure the Dash MN network against this threat

1. Issue a Dash MN Hosting Software License Dash could create a MN hosting software license. This software would go some way to protecting the Masternode network by ensuring specific criteria are met in order to host a MN by a MN hosting company. It would also enable us to gather valuable distribution statistical data on the Dash Masternode network that could help us keep the network secure.

The terms of the license will also detail specific working practises and security protocols that need to be met in order to host more than a specified number of Masternodes through the same hosting company. Security protocols would need to ensure that even if a hacking event were to occur the hacker would not be able to gain access to the entire MN network hosted by that company.

The software license would also automatically collate the number of MNs hosted by a MN hosting company and this information would be made available to the Dash network. This information would enable us to know the distributions of MNs and which hosting company is hosting them.

2. Limit the number of Dash MNs hosted with any one company The MN hosting software license would also set an upper limit to the number of Dash MNs any single hosting company could host at any one time. This would mean if they were breached by a hacker then only a portion of the MN would be affected.

3. Statistical data on MN hosting distribution We need to collate statistical data where our MNs are hosted and with which hosting company. This information could be made available to the MN network privately e.g. a digital signature from a MNO could be used to unlock the hosting data. This would enable us to make an informed decision who to host with to ensure that no one hosting company has the majority of our Masternodes. This information could also be gathered via the DMT tool during registration of a MN which would be useful for knowing how many MNs are actually hosted by hosting companies and how many are self hosted. This would give us an idea of how decentralised the MN network is.

4. Build a MN self installer. A MN self installer with control panel would provide a simple and easy way for anyone to setup a MN without the need of a dedicated MN hosting company intermediate. Perhaps a Dash developer could consider building a Dash MN self installer that anyone can use to set up a Masternode and control panel on any VPS host of choice. This project could be funded by the Dash treasury.

The problem is that even if we had a self installer the cost of hosting a basic VPN is more than what companies like Allnodes are offering. However if MNOs knew what the MN network distribution was and had a very simple means of hosting their own node I think many MNOs would opt to pay a little more to ensure decentralisation remains on the network.

 

[Bertrand256]

However, with the advent of the MN hosting companies, this has radically reduced the amount of decentralisation of the Dash MN network. And, as you will see later on in this post, this number is actually more likely to be closer to only one or two companies for hosting the majority of the MN network.
.

Pursuing to optimize the cost of maintaining masternodes is natural, but the consequence is centralisation of services. We saw in practice how one of the possible effects can look like, after the 24h power outage in the Paris OVH data center in November 2017. I think that the issues raised are valid and definitely worth discussing. It would also be nice if the representatives of hosting services let us know how it looks from their side.

 

[GrandMasterDash]

I've had this thought for a while now but my hunch is, this is a medium-to-long-term problem. I saw a post the other day that a Chinese hosting company had 30+ nodes, which is well away from the 400 you would need to begin contemplating this type of attack. I don't know where you got 51% from, that's a mining attack, I believe ChainLocks requires a 24 hour quorum of 400 and even then the odds of defeating it are minuscule. I refer you to Darren Tapp's comments:
https://www.reddit.com/r/dashpay/comments/ci36gq/it_is_very_clear_how_dash_is_leaving_the/

Your point is valid but I suspect / hope the consensus protocols will evolve and improve over time.

 

[Bertrand256]

After the implementation of ChainLocks, the "conventional" attack associated with the takeover of most of the hashpower does not seem very likely, however, the attack vector can be more sophisticated, and it's probably what @DeepBlue means.

Let's imagine that there is a bad actor whose plan is to take control of such a number of masternodes that will allow a high probability of building the entire masternode quorum in order to perform a double spend attack. His ultimate goal is more to destroy reputation of the network than to gain financial benefits. To achieve this he builds a masternode hosting service with such attractive and competitive parameters that after some time most of the masternodes find their "home" there. The MNOs feel safe because their funds are still controlled by their hardware wallets so their vigilance is somewhat dormant. But from the network's perspective, things are not so cool: the operator runs a modified software that waits for the mn quorum to consist only of masternodes controlled by him. When this happens, the software begins to forge transactions or in some other way destabilizes the network to undermine trust. When masternode owners find the ugly truth and start to "revoke operator", it's already too late - the reputation may already be damaged.

Note that this hypothetical scenario requires relatively low costs - mostly the cost of building the hosting service (100-200k USD). The cost of running the service is covered by the users. In this tricky way, one may be able to use someone's collateral for nefarious activity by "renting" it for a few dollars a month.

I am absolutely convinced that all known Dash operators are honest and want the best for the network, but - as @DeepBlue noticed - the bad actor doesn't have to be the operator himself. It can also be a hacker who infiltrated his network.

Therefore, probably the best solution is prevention and not allowing too much centralisation. The topic seems worth discussing right now, because trying to solve it once it occurs may prove quite difficult.

 

[qwizzie]

I guess we need to monitor this chart and try to spot any centralization forming there : https://chainz.cryptoid.info/dash/masternodes.dws

 

[DeepBlue]

I don't know where you got 51% from, that's a mining attack, I believe ChainLocks requires a 24 hour quorum of 400 and even then the odds of defeating it are minuscule.

@GrandMasterDash Thank you for your comment. My apologies for the confusion in my first post. Let me clarify. I got the >=51% value from the following article by Alexander Block https://blog.dash.org/quorums-in-dash-e1f19a66f4bf I will add the quote from that article here. However later in the article it mentions 6 out of 10 MNs i.e. 60%. The idea here is that a majority of the MN Quorum agree i.e. reach consensus.

This is a quote form Core team developer Alexander Block:

Reference: https://blog.dash.org/quorums-in-dash-e1f19a66f4bf
"What are quorums?
A quorum is a collection of entities that are able to vote on something. Every member is generally allowed to vote only once. If >= 51% vote for the same thing, majority is reached. Something either got the majority of votes or not, there should be nothing in between."


DASH Quorums current security model is making the following assumptions:

1. That the majority of MNs are acting honestly
2. It costs 1000 Dash to have control of a Dash MN
3. The MNs in a Dash Quorum are selected randomly and are representative of the total number of MNs nodes (currently around 4900 )

However all of the above assumptions may fall down if a MN hosting company hosts several thousands MNs and that MN hosting company is compromised.

The cost of running the service is covered by the users. In this tricky way, one may be able to use someone's collateral for nefarious activity by "renting" it for a few dollars a month.

As @Bertrand's mentions above that if there was a dishonest host, or a hacked host, the entire number of MNs that they are hosting could be "rented" out for a few dollars a month or potentially at no charge at all if they collect monthly fees from the MN for hosting.

Here are a few other possible scenarios:

Scenarios where MN quorums may not be acting honestly
1. Dishonest MN host - direct access to all MNs that they are hosting
2. A honest host but a dishonest employee working for that host creates a back door for a hacker (this allegedly happened in Binance where a dishonest employee created a back door for a hacker to steal 60,000 KYC Identities see this article: https://www.coindesk.com/binance-kyc-issue )
3. A hacker gains access to an honest host due to a security vulnerability.

Therefore the greatest vulnerability risk in my opinion is not if the majority of MNs can be trusted or not, but rather if the hosts of those MNs can be trusted.

All of the above would mean a hacker could gain access to a majority of MNs without paying the 1000 DASH per masternode.

I believe ChainLocks requires a 24 hour quorum of 400 and even then the odds of defeating it are minuscule. I refer you to Darren Tapp's comments:
https://www.reddit.com/r/dashpay/comments/ci36gq/it_is_very_clear_how_dash_is_leaving_the/

According to the following article by core team developer Alexander Block the size of a DASH Quorum can vary between 10 to 400 nodes:

Reference: https://blog.dash.org/introducing-long-living-masternode-quorums-76ea8b23a85a
Size of LLMQs
We will support multiple types of LLMQs, which most importantly differ in size and longevity. We have not decided exactly which sizes to use, but we are open to supporting LLMQs with as many as hundreds (e.g. 400) of members and as few as 10 members. It all depends on the use cases and their needs."

According to the another article by Alexander Block the Quorum members are selected randomly from the approx 4900 MNs

Reference: https://blog.dash.org/mitigating-51-attacks-with-llmq-based-chainlocks-7266aa648ec9
"As LLMQs are randomly composed from Dash’s Masternode set (currently about 4900 nodes), the distribution of nodes that have seen this block first across the whole network is statistically the same as inside the LLMQ. This means, that if 60% of LLMQ members have seen the block first, about 60% of the whole network should also have seen it first."

However how can we be certain that the selection of random nodes is not all from the same MN hosting company? e.g. is there a possibility that 10 nodes are hosted from the same company? Is it also possible for 400 nodes to be hosted by the same company?

What is the definition of "Random" in context of selecting the MNs that form a Dash Quorum?

The security from the LLMQs is assuming that the majority of MNs are acting honestly and that the selection of the MNs for the quorum is random. However I think we need to define the word "Random" in this scenario. If we took 400 nodes that happen to be hosted by the same MN hosting company would that be classed as random?

It is a reasonable assumption that selection of MNs is random but only if the MNs are trully decentralised. However if they are not decentralised an attack vector opens.

I guess we need to monitor this chart and try to spot any centralization forming there : https://chainz.cryptoid.info/dash/masternodes.dws

Thanks @qwizzie for this chart - very useful. However another question then arises. Who is to say that a MN hosting company (not a VPN host) could be using one or more of the above VPNs hosts?

In my opinion in order to ensure the security of the network when using Quorums we cannot simply use a randomly selected number of MNs. We need to ensure to use a selection of nodes from provably different hosts and to ensure that not more than 6 out of 10 MNs in the Quroum are from the same host. This can be achieved if we created a MN software hosting license as I suggested previously in my first post.

Useful Reference Articles on Quorums by Alexander Block - core team developer that runs the Dash Dev Blog site https://blog.dash.org/@codablock
https://blog.dash.org/mitigating-51-attacks-with-llmq-based-chainlocks-7266aa648ec9
https://blog.dash.org/introducing-long-living-masternode-quorums-76ea8b23a85a
https://blog.dash.org/quorums-in-dash-e1f19a66f4bf

 

[qwizzie]

And who will assign and manage those MN software hosting licenses ? If that will be a specific central organisation, it will directly undermine the goal of achieving more decentralization.
To be honest i dont really like the idea of having any kind of license, whether its in the form of a Bitcoin License (BitLicense) or in the form of a MN software hosting license.
It just provides too much control and power in the hands of a few people and could limit participation.

 

[GrandMasterDash]

@DeepBlue The blog post you cite was published 22 Aug 2018. Take a look at the bottom of DIP6, "Current LLMQ types". quorumThreshold is set to 85%:
https://github.com/dashpay/dips/blob/master/dip-0006.md

Yes, you would need to control thousands of masternodes to disable ChainLocks. You would then have a 24 hour window to coordinate with malicious miners to perform a 51% attack. During this time, new quorums would be forming and locking in.

I'm confident the intersection of miners and masternode operators is very small. But still, long term I think we would need some sort of AI to alert of unusual behavior and then auto-adjust accordingly.

 

[akhavr]

I'm not sure what type of attack do you mean? Say I'm the only hosting company that hosts MN. How can I attack the Dash network? Run custom versions of `dashd` that behave in a malicious way? Or what?

 

[GrandMasterDash]

On the plus side, the shared masternode hosters bring more end-users into the voting process.

 

[DeepBlue]

Take a look at the bottom of DIP6, "Current LLMQ types". quorumThreshold is set to 85%:
https://github.com/dashpay/dips/blob/master/dip-0006.md

Thank you for the references. I have read the above page and also all associated references.

Here is the table they gave for quorumThreshold limit
Quorum size 30 - quorumThreshold limit 60%
Quorum size 60 - quorumThreshold limit 60%
Quorum size 400 quorumThershold limit 85%

Earlier in the article it also states the following:
"quorumThreshold: The minimum number of threshold signature shares required to recover a threshold signature. It also influences the DKG as it is the minimum number of valid members to create a valid premature commitment and final commitment. This value should be at least 51% of the quorumSize. This is identical to the “m” in m-of-n."

Therefore presumably we can go down to as low as 51% for smaller size quorums than quoted above.


Dealing with the example of a Quorum size of 400 masternodes which currently appears to be the maximum size for a Dash quorum.

Consider the following scenario. A masternode hosting company could eventually host 3000 MNs + out of the 4900 MNs. This is possible over time if a MN hosting company offers an ultra competitive package e.g. $5/ month for hosting, with control panel and monitors etc. Such a host would effectively wipe out the competition. If this is to happen what would be the probability of 400 MN quorum being selected at random from the 4900 total and these 400 nodes all reside on the same MN hosting company if they are hosting 3000+ nodes? This becomes a real possibility.

If we look at the interview with Oliver business dev manager from Allnodes by Dashnews stated they are hosting 1700 Masternodes and that DASH MNs is a major one that is hosted with their company. Oliver however would not disclose the exact number of Dash Masternodes hosted with their service so we do not know for certain how many Dash MNs are hosted with them. Considering they have only just started out, 1700 MN is a substantial number of nodes.

See time code 1.00 in the video below onwards where Oliver states they have 1700 nodes and Dash being a "major one"

With time more MNO will migrate to services like Allnodes simply because they offer the simplest, cheapest and overall potentially best hosting solution in terms of monitoring tools making is very attractive for MNOs to move over to MN hosting companies like this. Currently there does not appear to be any cheaper or easier way to host a MN than through Allnodes. If anyone is aware of a cheaper and simpler hosting solution for a DMN than $5 / month / node could you post it here.

If, however, a MN hosting company becomes compromised by a hacker then all MNs they host could be potentially manipulated to deliver the result that the hacker chooses. If the infiltrator was smart they would wait, rather like a viral trojan, until a transaction of significant magnitude was to occur that could cause serious damage to Dash.

The threat may not come from a hacker. It could come from an insider employee, as was allegedly the case with Binance recently, or it could come from an organisation or individual that blackmails or threatens the owner on behalf of rogue party. There are numerous possible ways that rogue MN code could be activated on such a host. Because these scenarios are possible it is essential that even if these threats did happen to the operators of a MN hosting company they would posses zero threat to the Dash network. The Dash MN network operation and hosting must be trust-less for it to be secure.

Therefore if 100% of the quorum were compromised any outcome that the MN quorum needs to deliver on behalf of the network could be potentially manipulated to give a result the hacker has chosen. The threat could come from custom MN controlling code or software that manipulates the MN decisions itself either way the final result could be modified if all of the MN in the quorum were affected by the rogue code.

It could be argued that if there was a 100% rogue Quorum that the network would eventually discover the issue however what I'm suggesting is that by the time we discover there is an issue with a quorum it may be too late.

I would welcome feedback from developers to understand how an invalid Quorum consensus validation could not be of damage to the network.

And who will assign and manage those MN software hosting licenses ? If that will be a specific central organisation, it will directly undermine the goal of achieving more decentralisation.

To be honest I dont really like the idea of having any kind of license, whether its in the form of a Bitcoin License (BitLicense) or in the form of a MN software hosting license.
It just provides too much control and power in the hands of a few people and could limit participation.

@qwizzie I totally agree with your comments. We cannot have a centralised body in control of a MN hosting license. It ideally needs to be a form of decentralised control. One possible way is through assigning MN hosting companies a "trust rating". I will use the word "license" for want of a better word.

This is one idea how a MN hosting "license" could operate. The "controlling actions" based from information collated by the license would be the MNOs by the way they choose to act on information gathered. The license itself would be part of the protocol. The MN hosting license would initially primarily act as an analytics reporting agent to the MN network and the MNO would then know what actions to take with respect to hosting based on the information that is collated by the license. But later the license could integrate other security integrity checks on the hosting company.

When a MN hosting service is setting up a MN they would need to enter their License key as part of the new protocol. This would relay to the network the number of MNs they are hosting. This information could be cross checked against the data gathered from the DMT tool in which the MN owner would select from a drop down list the name of the hosting company they are using when they are using the DMT tool to setup their MN. The two sets of data could be compared. If the MN hosting company stats vary significantly from the data gathered by the DMT tool the MN hosting company trust rating would be lowered depending on the size of the discrepancy and this would be displayed on a MN network security control panel. This would signal to the MNO network that the hosting company could be hosting more MNs than the permitted maximum amount to ensure security for the network. The larger the discrepancy the lower the trust rating of the hosting company. Once the total maximum amount of MNs are hosted with any one company the License would not permit more nodes to be hosted with the same MN hosting company. However if they find a way to bypass this we would still know because the DMT statistics would not match. In order for this to be reliable all MNOs would need to use a DMT tool or something similar.

To ensure the integrity of a MN hosting company, and to ensure they have not set up several hosting website services each hosting company could be thoroughly vetted by DashWatch to ensure we know who we are dealing with. If a hosting company decline to obtain a MN hosting license then they would be given a trust fact of zero and the MNO s can make their own decision what to do. However I cannot see a MNO choosing to host with a hosting company that has a trust factor of zero.

Trustworthy MN hosting companies would understand the importance of decentralisation for the security of the network and would most likely agree to such a license.

The license analytics data could be published on dash.org in a control panel type display so that any MNO could refer to it before deciding with who they are to host their node with a particular host.

Even if we decide that there will be no limit to the number of MNs that a hosting company can host the analytics gathered by the license and the DMT tool would be valuable in ensuring that a Quorum never comprises of more than quorumThreshold limit from any one host. This would mean different hosts would be represented in a quorum making the quorum significantly more secure.

The above are only the basis of initial ideas on how a MN hosting "license" could be controlled by the decentralised decision making power of the MNO network by using information gathered from the License and DMT to give trust rankings to such MN hosts and the MNOs would act collectively to ensure the MN network remained decentralised.

Currently, I am not aware of any data that shows the distribution of MNs specifically by MN hosting companies. If someone knows of such a source could you post it here. Therefore if we do not have this data how can we say for certain how many MNs are hosted with any one company?

The ideas posted above could provide us at least some data to make more informed decisions to ensure our MN network remains decentralised and therefore more secure.

 

[GrandMasterDash]

@DeepBlue Personally, I think you're blowing this out of proportion. You're making a lot of assumptions and the kind of scenarios you're talking about seems to be a long way off, by which time we're likely to have other more pressing problems, such as quantum computing. The reddit link I provided earlier puts some numbers to this, showing how many possible quorums there are, and it's a very large number!

And don't forget, getting lucky to break Chain Locks gives the attacker a 24 hour window to also gain 51% of the mining, how do you image that will happen?

Do you not think in the time it takes to do this, that bitcoin iteself might be more prone to attack than dash? I mean, the Binance debacle demonstrates this is not as far fetched as some like to believe. As an attacker, which would you choose, bitcoin or dash? Bitcoin is now the easier target.

 

[DeepBlue]

You're making a lot of assumptions and the kind of scenarios you're talking about seems to be a long way off,

What I can say with certainty is the hosting of the MN network will most likely become centralised due to market forces acting on the hosting companies. I can say this based on my experience. I have 29 years business experience running my own enterprises as business development / marketing / and tech innovations director. I've seen many such cases occur in the past both in our field and in others.

I'm not sure what type of attack do you mean? Say I'm the only hosting company that hosts MN. How can I attack the Dash network? Run custom versions of `dashd` that behave in a malicious way? Or what?

We saw in practice how one of the possible effects can look like, after the 24h power outage in the Paris OVH data center in November 2017.

Thanks for your comment akhavr. Honestly, I cannot say what type of attack will happen. All I can say with certainty is that centralisation of control can lead to a single point of failure and a focal point which can make an attack easier than if we had a decentralised network. It could be a data centre failure as Bertrand has stated, or it could be a hack.


I think one point we can all agree, keeping a network decentralised provides more security, safety and stability to a network, than one which is centralised. The objective of this post was to raise awareness of the possibility of centralised hosting control and to suggest a possible solution. I have done that and therefore I have fulfilled my part.

The best people to determine if centralised hosting control or our MN network could present a risk to DASH are our Developers and DCG management.

 

[Sephiroth]

Hello. I’m the founder and CEO of the Allnodes service and I would be happy to share our thoughts about the topic. First of all, it’s important to say that we pay a lot of attention to the security of the project and of course we’ll constantly continue doing it. I understand your doubts, that’s why we are always happy to be in touch with the developers to implement an additional security at any levels.

From the very beginning we’ve heard a lot of questions about how it is possible to provide a product of high level for such a low price. “You need to earn money!” “You will go out of business because you don’t know what to do!” - and that’s only a few examples. So, if someone is interested in how exactly it works - here is the thing. Providing a good service for the lowest price possible is just a business model that is available for a business that has some resources and is ready to go forward instead of focusing on how to earn money only. We want to give people more flexibility instead of making them pay more. If somebody values the service more - it’s easier to add additional payments with operator rewards option. If you think that $5/month is enough for such service then we are still happy to have you onboard and ready to offer you another services around masternodes.

Talking about your ideas - let me leave some feedback below:

1. Dash MN Hosting Software License looks interesting, but as @qwizzie has already said, that means some centralization. If it’s not limiting the Masternode hosting service and even helps it to be better - then such kind of collaboration between the services and Dash development team could definitely be useful. The only question that may rise is a licence. That sounds way too serious and it has to be some sort of verification process, which allows people to trust the service more.
   
   
2. The 2nd and the 3rd points honestly don’t seem too optimistic from the side of the service. Technically, you can’t limit the number of hosted nodes and until you get the full access to all the system and servers inside - you can’t be sure how many nodes exactly are hosted somewhere else. Giving such access to anyone doesn’t seem healthy for the business, especially when the service supports lots of different crypto assets and invests all the resources of its own and not funding from some long-term proposal, which could be more reasonable in case you’d like to have the internal information available in public.
   
   
3. Self-installer will not help people solve all their problems. As we’ve noticed, the node installation is not the only problem for non-tech users. It’s often too hard for such users to maintain the node, to check its statuses, to understand what to do if something goes wrong, to manage the updates. Sometimes all these things are hard even for us, with around 20 people in the team, so what can we say about some solo enthusiast, who likes Dash and wants to have a node to support the network and make some income? Of course scripts or installers will not help him avoid any issues. In that case, hosting services bring adoption and allow more people to be involved in crypto.

As for the risks in general, if some hosting can get thousands of nodes, I think it’s more realistic for the new blockchain networks. For example, the network has been launched recently and it has just started supporting masternodes and some service has provided the hosting from the early beginning - then there is a chance that lots of nodes will be hosted in one place.

In case of Dash it seems absolutely impossible, because Dash has a long history. The hosting services became popular in the last 2 years, but there were already thousands of Dash nodes in the network by that time, which means that there are lots of technically educated people in Dash community who can manage their nodes by themselves. Moreover, the cost of Dash nodes is very high, that’s why there is a small chance that one day thousands of nodes will come to the network and be taken care of by some single service. So finally, under these conditions it seems unreal for any of the hosting services to have thousands of Dash nodes onboard. Of course, it’s still necessary for any service to pay attention to the security options, but I just wanted to say that even in some really unlikely scenario, it seems like something neither crucial nor dangerous to be able to destroy a stable Dash environment.

 

[DeepBlue]

@Sephiroth thanks for your reply. It is good to hear the side from a hosting company. Could you clarify if I understood your business model correctly. You mentioned your hosting model is $ 5 / month and you will make extra money if the Masternode owner opts to optionally pay more?

I do not know how you can make a healthy profit from hosting at $5/month if you factor in labour time and also questions and support which will inevitably arrive even for a software package like yours. I don't think any company could compete with that.

With a business model like yours, offering MN hosting at only $5/ month and offering a control panel and very simple setup I mentioned above market forces will dictate that MNOs will move to using the cheapest and best solution. Currently that appears to be your service. I pointed out in my original post this is likely to lead to centralised control of the hosting of the MN network over time. What would be your views about this? Do you feel it could expose the network to a greater risk?

What are you thoughts about a hosting company and how they should handle the the security of the network?

It seems from all the replies in this thread and the downvotes on my posts nobody here sees centralized hosting control as a potential security threat to the MN network. Do you share their opinions on this?

 

[Sephiroth]

@DeepBlue Right, the operator rewards option allows us to give people a choice whether they want to pay a fixed amount of $5/month or to pay a percentage from the rewards. We will finish that option in the nearest time. We've got a lot of positive feedback regularly and some people really want to pay more, but we don't want to force people to do that, we prefer to give them an opportunity to choose.

Talking about risks, honestly, I've tried to represent my opinion about that in the last two paragraphs of the previous post. In case of Dash I don't see any risks for the network because of the reasons above. We don't feel even in years from now the amount of Dash Masternodes on Allnodes service will be too high to be able to damage the network. And I think it's mostly the dev's responsibility to handle the security of the overall network. From our side we are taking care of the internal MN owners data to prevent any malicious actions with Masternodes management. And as I've said, we are always ready to work closely with the Dash Development Team if they need our help to implement the additional network security options. We can assist here, but we can't lead that process by ourselves.