Let's address the /24 subnet limitation ipothetic removal

@SGC
Of course, that’s exactly the point. It should stop the abuse. Maybe I wasn’t clear… let me elaborate.
Ipotheticaly speaking, if a deposit is allowed, a SNO that wants to run the second node, when the first one is not full, on the same IP, he will have 2 options:
1.go with the standard way, with no deposit, held amount and the split ingress.
2.go with the collateral way, make 50$ deposit, and get full ingress on both nodes.
If the first node is full, dosen’t make sense to go with 2. This is out of discussion.

Now, if you want to start the 3rd node and the first 2 ones are not full, you again will have the 2 options:

  1. split ingress.
  2. deposit 100$ and full ingress.

The discusion was how to limit the abuse of someone who wants to start more than 2 nodes at once with the same amount deposited for each. That’s why I sugested “double the amount”.
I’m not in favour of centralisation and more nodes on the same IP. Even 2 nodes with full ingress is wrong, I admited that, so no point in going further with this. And this deposit is like betting on or buying bandwidth. Looking at it now it seems a very bad idea.

I like the idea. But what can force me to not start new node over a new VPS IP, which would be much cheaper?

You’d get a deposit back eventually. VPS payments are permanent and recurring. Of course that is assuming your node never fails and you exit at some point.

\24 rule is more isier to manage to storj it automatic, but deposits someone shold managing, it westing of human resources.

I think that there should be two levels of aggregation - all nodes with the same IP aggregated to one ip-node, tjen all ip-nodes in the same /24 should be aggregated into one subnet-node. Right now only the second part is done and it could lead to node count competitions.

Let’s take a hypothetical scenario that someone in my /24 starts a new node. We each have one node, those two nodes get aggregated into one and each of us gets half the data (compared to a single node in the /24). However, if I start yet another new node, now there are three nodes, each get 33% of the data, but I own two of them, so I get 66% of the data. In this case it would make sense for both of us to have as many nodes as possible in an effort to get more of the single-node data.
If one set of nodes is slow and loses races, it does not help the other nodes in the same /24.

1 Like

it has no economical sense to compete in such way. also, vetting process wont allow you to run big amount of nodes. no you can but this process will take huge amount of time and increase this process time for previous node that is not finished it. so most probably those hdds will never pay for themselves.
Also, running additional node in your scenario will give you additional ~16% of overall data, what sense to buy additional hdd for this 16%?)

Without realizing it, I made 2 problems threated as one: the /24 subnet limitation and the held amount, more exactely if we should be OK with a deposit for:
A. Removing the /24 subnet filter.
B. Replacing the held amount.
These 2 should be threated separately.
I/we arrived to the conclusion that A is bad for the network and us.

For B I should start a new thread. I don’t remember reading a debate on this, just some proposals. I hope I’m not borring you with these debates, but seeing that Storj team is open to listen to our ideas and sugestions, encourages me to give them more feedback.

I see your point, but node selection is part of the traffic flow and needs to be super fast. Having the /24 aggregation already slows this step down a bit and your suggestion adds an additional aggregation. If it can be done fast then yes, I agree.

It’s a classic game theory problem. If each node operator is selfish, both will be worse off, but if only one is, you can basically chase the other person away.

I think this only has downsides for node operators. Instead of having lower earnings for a while, you’re out your own money and actually risk an upfront investment. And it still doesn’t help you getting to profitability faster as you’re starting out being down the deposit amount.

1 Like

I made the new thread and I’ll reply there.

Who said I would buy HDDs to run the new nodes? I could create as many VMs as I want. OK, each node should have at least 500GB dedicated to it, but still. Yes, it’s against ToS, but nobody would know, right?
If it made sense to me now, I could spin up 10 additional nodes. It does not make sense now, but if there was a node on my /24 it would start making sense. If the other operator stays wit one node, I’ll get 91% of the (single node) traffic, while he will only get 9%, unless he also starts new nodes.

The current code is quite a lot slower than it needs to be, which would suggest there’s decent enough compute budget for node selection.

I’m less worried about compute budget and more about milliseconds. Since this process directly impacts time to first byte. If it’s true that it’s inefficient then that needs to be fixed to ensure better TTFB.

By compute budget I meant the amount of CPU cycles you can spend on the process of selecting nodes. There should be nothing to worry about right now, I doubt it takes more than a few microseconds now.

How do you identify the multiple nodes are by the same SNO?
How will you differentiate between someone wanting to run another node and someone just having a neighbor?
If by email address when registering that is easily changed and if by wallet people can just register another one though if it is against TOS.
Many isp’s offer multiple ip addresses you you can’t even guarantee the use of the same mode ip will track them.

Node selection only impacts uploads, TTFB probably is not as important as for downloads, though maybe I’m wrong. Also, TTFB already is rather long, 0.1% longer won’t make a difference.

However, I admit that I do not know how much this double aggregation would slow things down.

@penfold
I believe I was thinking at nodes behind the same IP.

So why wouldn’t an SNO then just change that ip to get around the problem? Since it would be the same subnet there is no point doing it now - but there would be with this change.
Even home grade unifi routers have the ability to add multiple ip’s…

1 Like

Yes, maybe you’re right. Clever people always foud ways to get aroud rules.

14 nodes in total here
All in one apartment, on 1 PC.
All on VPNs.
All IP’s from different country
All has no neighbor node
(in 2 case i saw 1 or 2, but i changed the server instance, and it was alone again,
also my nodes are full now, so don’t need more filling)
All VPNs for total $10 a month.

^
I didn’t notice any limitations for me. Sure it adds latency for STORJ customers! TTFB.
Costs me $0,71 per node, its a lot Yes if my nodes are around 1 TB, but if it was 8-18TB then it’s like nothing for ability to fill 7TB in under a year. Like i was able to do with one node. Just couldn’t find right time to upgrade more HDDs, always more important things… but the setup is there!

Time. A configuration of a port forwarding with VPN is significantly easier for what i discovered.
No playing with Your home router at all.
You just make lets say 9 virtual machines on 1 PC, each with it’s own windows, and You install a VPN app, chose location, and in the panel of a VPN provider You just set the port forwarding on that location, and voilà!

^
It is. Upload is 15-30Mbps, per a node, and my connection is 1000/300 fiber so yea i can handle all nodes. its a perfect setup. bypassing all that /24 rule nonsense.
For 3 and half years working flawlessly.
So much of a decentralization of STORJ as of now.

^
Sure it is. For me.
Because i have found great VPNs, and i was searching back then, not gonna lie.
But for the network? and the future of STORJ? …
When it privilege big SNOs, that can go 18TB HDDs per node?
and buy VPNs? or some deal with data centers?

^
Sure it would. If bandwidth price for customers won’t go down, there would be equally slow HDD filling for everyone.
Now, only ones who either have 1 big HDD,
or bypass 24 rule with many nodes 1 location, get’s decent traffic, to fill nodes to the full.
If You get rid of /24, it will take that advantage out of them.
Now people in home who have 1 node, and want to add 2nd or more,
have to go big in TB so it would be worthy to pay for some VPNs additional IPs,
or get filled slowly.
It discourages small TB HDDs owners, and so the decentralization.
Because too many nodes in 1 physical place atm, imitating different locations, to bypas /24 rule, and You don’t even know how much % of a network.
If /24 rule would be gone, then at least, You would know what the real numbers are?
As of there were no need to pay for VPNs, or additional IPs pools?
Ppl would drop that costs happily.

But imho You would need to watch what data You are distributing to the same /24 pool,
You know, not too much pieces of the same file.
So there should still be some limitation to get data in same network,
but a reasonable one, not like that kind it is now with strict /24 rule.
So there would not be a repeat as with v2, like @Pentium100 mentioned.

What?
How its prevents this? I though it encourage it!
I think they got larger address pools to choose from, than same /24
and they are using it, to bypass 24 rule.
Like in my example.
Tho VPNs are not data centers servers (VPS) but the VPNs traffic goes via data centers? i believe.

actually i didn’t realise i can drop those VPNs now, as my HDDs are full,
if im not going to expand HDDs space lol, ohhh man… still hesitate, if You going to nuke the network future with payouts lower by roughly half,
i don’t know if there’s any future for STORj at all.
tho, with bigger HDDs i would sure profit till the end!

So much of a provocation, but to be serious,
that’s why i think all here is like in clock mechanism, it interlocks itself.
if You take one gear out, a pinion, others are not working or malfunctioned.
Therefore, it is necessary to look holistically and use strategies that are known for their effectiveness, throughout history.

That’s why i wrote this here as You probbaly already saw,
i swear i was not on drugs, just passionate.