Will there be farming pools on SAFE network?

As she often does, my non tech gf asked me the obvious question I had not really thought about.

Is SAFE less susceptible to centralisation through farming pools than bitcoin with its mining pools? I hope so, but my immediate thought was that there’s an incentive here, just as with bitcoin. Is there a difference?

3 Likes

I think pools of people could get together to share rewards. Would not be easy as they would all have to change their wallet address and the pool would have to believe that to be the case. So maybe some external mechanism perhaps? Never say never but I cannot see it just now.

Its critical we get safecoin payments within the costs of running a node and not to much that would incentivise data farms.

4 Likes

Could it be done with a smart contract system?

I don’t see the marigin in it.

The reason mining pools work in blockchain systems is that the rewards are in sizable chunks, meaning that if you mine by yourself, the lottery strikes big when and if it strikes, but it might not. So pooling gets a proportional return and takes the maybe out of it. gives a more predictable ROI.

GETS are already spread out pretty evenly throughout the network, so the opportunity to get some safecoin is already accomplishing what the mining pools are trying to do = pooling would probably inhibit farming rate.

3 Likes

Why do you think pooling would inhibit farming rate? That’s the incentive I see - reducing costs and increasing performance through centralisation.

Because the SAFE network is INHERENTLY decentralized. A blockchain is distributed, but is itself inherently sort of a central locus, even if worked in a distributed fashion. Rewards can be horded to a central entity or group by amassed hashing power, solving a central problem.

In the SAFE network, by contrast, the points which allow earning are, by design, spread evenly throughout the network. So anyone who wants to get safecoin will get it in fairly direct proportion to the resources he puts in, spread evenly over time and consistency. Each node can only increase its rate of earning by adding time in reliable service, decreasing response time, etc. Adding some pooling mechanism is just an added burden and would, I think, be counter productive to an individual farmer. Think about it: A farmer already gets in direct proportion to the value given to the network, and on a bitesized scale, so that there are not any bonanzas to wait for. How would he profit from collectivizing? He’s already doing his collective part by being an ANT farmer.

7 Likes

Simply speaking: the granularity of the SAFE network is much finer.

A micro-worker doesn’t need to pool his work because it’s not paid by the hour. It’s paid in 5-10 second increments.
Same here.

3 Likes

Neither of you have addressed my point. I didn’t say that I’m concerned because the incentive to pool is the same as bitcoin, I said:

That’s the incentive I see - reducing costs and increasing performance through centralisation.

If pooling can increase the rate of reward that’s a powerful incentive, so maybe we need to put some more thought into whether this is the case, and whether pooling is feasible.

2 Likes

I think the answer covers that - units of work are embarrassingly parallel.
Pooling therefore cannot be effective.

I understand the rationale behjind your assertion, but it doesn’t adequately address the question of whether there are risks for SAFE in this. It is fair to say “I can’t see any attacks” or “I can’t see any incentive for pooling…because of what I understand”, but what I am saying is that I think the question is unclear and could be worth some analysis. This you are not presenting, which is why I’m saying it does not answer my points. The difference is between stating a belief, and presenting your analysis.

I remain to be convinced that there are not going to be ways that people can create efficiencies that, like bitcoin mining pools, are based on collaborations that create centralisation risks for Project SAFE. You are asking me to be reassured of that by your statement that you don’t believe this! Well, I’m not.

2 Likes

Im concerned about this too. I know David and team have looked at this very carefully and are prepared as can be. I think until the network is up and running we just wont know

What you’re asking is for the community to look into the future and assure you something we haven’t thought of yet won’t be developed… I’m sorry, it just can’t happen. The system was designed in such a way to minimize the possibility and reason to desire such a setup. Beyond that, I think we are going to have to wait and adjust.

There was talk at one point of disincentivising overly large nodes. I’m not sure if anything came of that.

2 Likes

What I’m saying is that “pooling,” in the sense I assume you mean, isn’t possible on the SAFE network, or if possible, wouldn’t result in more efficiency but less, thus reducing the reward.

Now if you’re talking about large companies, or whatever, putting up lots of nodes on high speed computers, located on ultrahigh bandwidth trunks, thus increasing their reward due to more reliable response, etc., cheers. I guess that would be centralization after a sort, but it would be in competition with others doing the same thing, as well as the rest of less well equipped individuals in the world who will be running their home nodes, maybe being less efficient but still being able to farm effectively, if less efficiently.

If we’re still not understanding, define what you mean specifically by pooling. Maybe we’re using the term differently.

My use of the term refers to various actors (perhaps large and small) assigning both their resources and rewards to a central pool of some sort and then taking the rewards back in proportion effort/resource put in. In a way, that’s what the SAFE network already does atomically, so any further effort at pooling would be superfluous. (This is, I think, the key point.)

Rackspace might decide to start running nodes on some of its servers, on high bandwidth trunk lines and thus be really reliable, low-latency contributors to the network, but it would profit them nothing to team up with me or you, or even Amazon (and I’m not sure such a team-up is possible, not to mention practical). The only way anyone would profit from such a pool would be due to a miscalculation of proof of resource that gave a less powerful, less efficient node more credit than it merited. Then that node MIGHT skim some marginal advantage. It might also go the other way. But who’d want to play?

2 Likes

Everyone commenting so far seems very confident of this, without providing analysis of the ways this might be achieved or demonstrating why it is not possible. Or, some comment to say that we can’t predict the future therefore stop worrying about it, and by the way MaidSafe have probably already addressed the question!

I think we can do better than this folks. We can, just as with considering potential attacks, think about the ways that may be achieved and consider how to mitigate the issue if it is deemed a threat. I get that you guys are not worried about this, and that’s fine, but you can not been able to explain to me why you think pooling to improve farming rate cannot be achieved. I’m only, at this stage, suggesting we think about that - as if we were trying to do it - and see if we can come up with any approaches that seem feasible based on what we do know.

@fergish I think your point about whether I really mean pooling (ala bitcoin) or a more general centralisation risk (such as rackspace/Google type scenarios), I am referring to the former, but it seems to me there are other ways of pooling than this. Coming together to fund a rackspace/Google type approach isn’t quite pooling, but it is still a threat to SAFE so needs to be handled, though maybe on a different thread.

I’m clearly not finding others who are sufficiently concerned about this to put effort and thought into it, which is fine. I may give it more thought myself, but I hoped to interest more heads in this because I don’t feel I understand the system well enough to arrive at a conclusion one way or the other.

I certainly don’t feel I can confident about saying it can’t or won’t happen because… SAFE is designed to prevent it … without access to an analysis to that end.

They wouldn’t necessarily team with you or I.
They could also team - I think this is way more likely - as “Corporation A Team”.
But it would dramatically cut into their margins and in all likelihood they wouldn’t be able to justify such investment (their farming work wouldn’t be that much different from any other node on the network).

If SAFE worked to “rebuild” (I don’t know the SAFE term) itself closest SAFE nodes on the network, then SAFE data hosted at Rackspace would prefer to rebuild itself to nearby Rackspace nodes and that’d provide better rebuild times so as a group those nodes would be relatively better rewarded than if they worked individually in dispersed data centers, but as far as I know that’s not how SAFE works.

Another possible advantage of clustering (for pooling) would be for low latency apps where you’d want all chunks of your files to be high bandwidth and low latency (UHD video streaming), but I seriously doubt that such clustering would be interesting to the likes of Rackspace because they already do high-value hosting and charge waaay more than they could get on the SAFE network. Why would they de-brand (even if they formed RackSpace Pool, it’d be hidden from SAFE apps) themselves and abandon their investment in customer relationships, support and so on?

Even these two scenarios are unlikely, but I can’t come up with any better…

If i remember correctly, the problem was that implementing code that would deter pooling also would inhibit early adoption. I thought maybe a trigger that if certain conditions came about certain code would be implemented

The corporate/NAS type overwhelm is indeed another thread, one which has been discussed at some length, and probably should be further.

On the pooling line, though, I’m not saying that some other means of collaboration is impossible or shouldn’t be considered. I’m simply saying that pooling in the sense we’ve come to understand it from the bitcoin space is not an issue as far as I can see, because SAFE is a different critter. I’ve explained why I think so and, I think, given cogent analysis as to why I think so. I don’t claim to have it all taped, so if you see a specific senario that shows how such pooling could be profitable (or even be accomplished at all), spell it out and I’ll listen.

1 Like

This seems to indicate a misunderstanding of what a “near” node is on the SAFE network, which actually has nothing at all to do with physical proximity, but with “nearness” based upon node addresses, which would place four connected nodes at random locatioins throughout the world and data chunks stored in even farther-flung arrangement. See Shortest distance between two points is not always a straight line | Metaquestions for David Irvine’s clarification on this.

So “clustering or pooling” are not meaningful terms in reference to the SAFE network, at least not as you use them here.

2 Likes

Why is everyone concerned about farming pools? Presumably the concern would be a pool getting so large that it could manipulate the network to their advantage. However, everyone in the pool would have to agree to that outcome AND trust that the maintainer of the pool wouldn’t screw everyone in the pool too. Seems logical that people participating in a pool would leave before this become a problem. I’m not too entrenched in the bitcoin world, but isn’t this happening already? People deciding to leave pools so it doesn’t exceed (or continue to exceed) the magically 51% barrier?

As for farm pooling, the whitepaper indicates that pooling could be a good idea if you are trying to maximize the coins you mine:

The mining interval allowed for a vault is determined by its contribution to the network. The interval is calculated as follows:

for each put attempts to the vault, when healthy_space is greater than group_average / 2 :


stored_space: the total size of chunks that have been stored to that vault by the network
lost_data: as data is stored on a node it may switch off or be otherwise unavailable, we consider this to be lost data. This is a critically important measure and in no way means the network has actually lost data as replicant copies are always available. This is a common practice for a node on the network.
healthy_space (h.s.) : h.s. = stored_space - lost_data ------ ①

This whitepaper tell me that I want my healthy_space to be twice as large as others in my group. This will prevent them from having a chance at a mine request in my group. Achieving such large disk space could be difficult by myself, but I could create a pool with a single vault to increase my storage space. The users in my pool would run a secondary network, whose design matches the MaidSafe network exactly. Storage requests would be filtered from the primary network to the secondary network, and payouts would match the healthy_space on the secondary network.

Can anyone spot a hole in this plan?

1 Like

This is the hole. Your space does not prevent others from getting requests.