please read it here,
2 Likes
I never said condoned. But the response here is significantly different in other places.
for example in this thread: Nodes uses VPN to bypass /24 rule
- Not a single official response from Storj and 2. Posts from some SNO’s indicating how they use the vps’es to bypass the /24 rule. Again. No consistency with the above statement.
2 Likes
That post is from 3 years ago, a lot of things have changed since then. I will bring this up with the team to get an update on our current position on this subject.
4 Likes
Thanks for tagging that old thread, I will also bring this up to team leadership and hopefully there will be an official reply.
3 Likes
To be fair, it hurts to see somebody calling me a cheater.
I have asked several times on the Storj position over /24 limitation, most recently here, with no luck to get answer. There was full thread about this without official position against that.
I understand what is written in ToS. But these are the first posts known to me, where Storjling writes something against.
Maybe it is just me, but in two years I am here, all the time I had a feeling this is quietly tolerated, because these operators have skin in the project. Investing much more time, than just spinning one node, paying VPSs to provide the service and surely most of them has better HW to run the nodes. They have the skill and can get bigger with the network demand.
I know we have enough of data storage now, even with small home operators, but what brings the future? I just though, this will be resolved in a way, that you will be able to earn something worth the invested time in the long run.
Actually, I care about this as I care on price for stored TB, because earnings comes from price and number TB stored.
We mostly suggests to use what you have now, not to invest in something. It’s not only about ToS, but more like a balance between the customers’ demand and supply of new nodes. We do not want to concentrate a lot of data in one physical place, because in any problem with that place we could lost a segment (we never lost any single segment since the launch), but if that happen, it could scare away customers. So, we do not like the behavior when someone is trying to bypass the rules, however, we also believe it should be handled by a protocol, because we cannot lean only on altruistic behaviour (see Storj Whitepaper V3 for more details).
Right now it’s required to do not circumstance the limit of nodes per /24. And if that would be discovered, your nodes could be banned.
P.S. lowering prices should also make behavior to circumstance of this limit make economically not viable. But I personally prefer to have something more mathematical than pragmatical 
5 Likes
It would have been nice that when there was an explicit thread on the subject for Storj to post that response instead of nothing… Given that for a long time the ToS were not actually accurate in a number of areas as to what was tolerated I can why it was confusing for some people.
2 Likes
Yes, I believe we owe that update of ToS for a long time. However, I do not control it.
For now the Storj’s position as far as I understand:
- you can run multiple nodes per IP, if they uses a physically different HDD per node;
- you are not allowed to circumstance the /24 limit with any behavior, which could lead to place more than a one piece of the one segment on your nodes, running on the same hardware and/or in the same physical location;
- you must use the same wallet in each of your nodes.
3 Likes
This last one might also not be an absolute - like if you want to experiment with zksync or Polygon (when that was active). I know when I had 3 nodes active I only moved one to Polygon for a while - was not happy with it and moved back to L1.
But, I’m compliant with the rules as you stated above. 
Hm. Fair enough. It should be the same wallet, but might have different wallet features
Right now it’s more relevant for L1 though.
However, I do not know, what to do, if your primary wallet doesn’t support any of zkSync, other than force you to use a Metamask 
Perhaps it’s not a problem, because you do not have any other option for zkSync Era right now, except using a Metamask.
When they were alive I used Numio for my zksync wallet. but I used a MEW wallet for L1 (and still use that same wallet) So, yes exactly. different features. And unfortunately despite the good support Numio sucked…
Every business should find their source of funds and profit…
1 Like
Well then, it’s a bummer. Can I run 7 nodes on one array? Because since nodes can’t shrink, this is the only way how I can share space from existing array, that allows me to reclaim it back, as needed, by nuking nodes one by one.
1 Like
technically - NO. And you CAN shrink your nodes. By setting allocated to zero. This is not fast, but common, why did you spin it up in a first place if you know, that running multiple nodes behind the same /24 would not give you more data (profit)?
Are you circumstance a /24 limit?
I just explained why in the same paragraph. But here is a breakdown:
Let’s say I have 10TB free. But I’m using up 2TB per year for my needs. So, I start 5 nodes, 2TB each. When I need space every year, I exit one node per year.
If I started one 10TB node and needed 2TB space back my only way is to kill the whole 10TB node. I don’t see how that would be beneficial for anyone.
Numbers may be different, but this is the gist. I can’t wait until it slowly deflated by setting size to zero because it’s non-deterministic. It may never deflate.
And yes, I’m aware that all of them share ingress.
The question was — the “1 node per hdd” rule clashes with “don’t buy anything” suggestion, because I already have array.
And also let’s say I have array of 8 disks. Can I run 8 nodes? I.e. is 8 nodes per 8 disks ok?
No, I don’t circumvent anything. Today I have one node per array on three different arrays. But I’m thinking to spin multiple nodes instead for the reasons explained, before they fill up.
I wouldn’t take it too personal. I don’t blame you for asking, but this was never an intended way for nodes to be set up. And it is against tos for the reasons mentioned previously. Just because Storj hasn’t yet done anything to take action against it, doesn’t mean they won’t. But I get where you’re coming from.
There is of course a big difference between quietly tolerating it and condoning it. But these statements are probably true and as far as I can tell (I did my own calculations a while back based on what I think was one of the biggest node operators with over 300 subnets), there is no current risk to data. That said, running those setups that go against tos is risky, because they do tend to involve fairly large investments and could be taken down by Storj if they decide they pose too much of a risk.
It’s reasonable when someone so openly asks how to circumvent the implemented limitations, that you won’t get any help with it. You’re also not getting that extra data out of nowhere. You’d be taking it away from other node operators who don’t implement these circumventions. So expecting others to help you with it might be a bit much to expect.
Mentioning the same location would also mean you are not allowed to run multiple nodes in a datacenter that natively has access to a wide range of IP’s. This is a tricky issue, as those could be quite valuable to the network, but also lead to some centralization. It’s hard to draw black and white lines. So yeah, some mathematical solution to this would be best.
These things make it so tricky. There has been talk of a partial exit in the past that would allow you to actively shrink your node. In my experience, nodes only shrink a bit at first if you lower the allocation and then practically stop shrinking. It’s not a viable option. I would say in the scenarios you describe it’s up to the node operator to make sure it still performs well. I do something similar, but on a read/write SSD cache accelerated array. I know it can handle the load easily and won’t have any negative impact on the network. But I also understand the general rule to not do this.
1 Like
If we already speak about ToS, Stroj itself breading today it own ToS.
So it it outdated.
As agreements are always is a 2 way road.
Your right its pretty much storjs fault for allowing people to cheat to begin with, Tell people its ok to use vpns which then allows everyone to cheat cause thats all they gotta do to run more nodes with more profits, For allowing it to happen and at the sametime telling people they cant do it. Which is what has lead to the price decreases in the first place. All people gotta do now is spin up new nodes get more IPs = more nodes in one location… Of course it costs the user more to cheat but that doesnt seem to stop someone from running over 8000+ nodes on datacenters Ips.
2 Likes
I wouldn’t say they tell people it is ok, BUT there has been NO consistency from Storj on the issue so they are to blame. Letting the ToS become outdated is the perfect example of this. It’s the foundation document for the rules of the game. It should be updated.
Back in the early v2 days we had this situation where if you ran a node you got some money, like $1. I forget the actual earnings, but it didn’t matter if you had any actual data. There was just this incentive to grow the network back then. So, some SNO’s scripted installations and had single servers running thousands of nodes. They were worthless as nodes, but they did this to earn the incentive and make money.
When we pointed out that they were gaming the system, they were offended because they said they were working within the rules we setup. If we didn’t want it to be that way, we should change the rules. Which we ultimately did, but for some months a lot of node operators had a pretty good profit for not having to do very much.
Storj continues to enhance the network and at times we tighten things down. The terms of service are the legal obligations SNO owners are asked to follow. We agree they need updating, but they won’t be updated to say that circumventing the /24 rule is ok. Just that you can likely, run multiple nodes at one location. If the company determines it needs to create further barriers to prevent centralizing the data, I am sure they will announce what those are if and when the time comes.
2 Likes