Ok, but you might have the technical skills to do it but not the the money. But many don’t have even that. Just read the forum topics here and you can clearly see how so many don’t have the ability to deal with even simple problems. That’s all I mean. I know you don’t have to be a total wiz to figure it out, but you do need more than the average Joe has.
Yes that is true not the avg joe on here sure. Ive been here a long time I seen alot of people come and go since I started. Help many along the way.
Storj could also look into using the Autonomous system in selecting nodes for storing data.
If they did, all /24 subnets I’m currently using in our DC, that are tied to our AS (AS49974) would be treated as single provider, and my nodes would get way lower ingress.
I could then start using VPN or VPS with reverse-NAT, but each VPN/VPS would have to be tied to a unique AS which are not used by other nodes, to gain full ingress traffic. It is possible to do, but more complicated compared to how “easy” it’s possible today.
A lite bonus by using AS is that all data are spread among very different networks among ISP’s/DC etc., and not ending up on 100 different /24 subnets owned by AWS / Hetzner / google…
Currently, there are more than 90.000 AS in use on the internet.
How many of those are covered by SNO’er, only Storj themselves know.
Th3Van.dk
5 Likes
I’m using 30 x /24 subnets for all my primary nodes, and 1 x /24 subnet for my backup nodes.
There are currently ~6,6 TB of free space on the server for my backup nodes. I’m guessing that the free space was reported 501 time back to the satellites which equals ~3321 TB which are very close to the 3 PB drop (35.552.856.395.309.920 Bytes - 32.231.839.565.127.730 Bytes ) = 3.321.016.830.182.200
Bytes
I have not looked into that for my backup nodes, since it’s more important to keep them up and running.
Th3Van.dk
3 Likes
Oh of course. There ARE ways Storj could use to essentially “weed out” the whales from everyone else. Even building their own relatively simple algorithms to track certain node metrics would be pretty effective, which I would imagine is already done to some degree. But the simple fact that the whales that most people are referring to are the ones that are at least honest enough to actually use the same wallet / email address to run their nodes already gives Storj a pretty good indication of who many of those individuals are. But hey… let’s not start advocating for that, huh? lol
I would have to assume that Storj is aware of ways to do this, but on the other hand are also aware of the same points I’ve made in other posts. Quite simply, cloud storage is only profitable at scale… currently for Storj this is at least a couple hundred TB before it’s actually somewhat profitable from an investment point of view. If they decide to take that away, they will inevitably loose their whole platform. People simply aren’t going to commit costly resources to something that doesn’t offer a return.
That said, as the project continues to grow it will eventually reach a point where we can all stop fighting over the crumbs. There will be plenty to go around. But without whales now, that will never happen. If people want Storj to succeed they need to be profitable. Now even though I think there’s wiggle room to increase customer pricing, the fact of the matter is that lower prices can definitely be a selling point… and where Storj want’s to stay can only be achieved by keeping their costs down… and the only way to do that while still being profitable to SNOs is at scale. Now I could be wrong, but I’d bet that even if they add something to their ToS targeting whales, they probably won’t actually do anything about it, and ultimately the new ToS will just give people more things to complain about.
Amazon doesn’t store a single file in all of their data centers. Storj does. Unless Amazon actually implements a distributed protocol like Storj’s, for the purpose of this conversation, Amazon is 30 separate non-distributed regions that each happen to have the same protocols, not a single distributed storage system.
If, however, Amazon started a massive number of Storj nodes, maybe on their own satellite, that would be a different matter. I suspect 30 would actually be enough if operating each single one to a data center standards. Backblaze is close to doing a similar thing, they do n=20, k=17 and not really loosing many files.
The n=80, k=29 numbers are to cater for clueless node operators who expect the Windows installer to think for them, not seasoned sysadmins.
1 Like
This makes little sense.
- Regardless of node operator ability the hardware can be simply bad, network card can die or datacenter turn out to be horribly unreliable.
- if that was the case then why not vet only the first node for each specific operator and have the rest of the nodes skip vetting? This would be ridiculous for exact the reasons discussed.
Node long term uptime reliability maybe correlates with operator skills but not completely. It’s an approximate proxy to uptime with extra steps. Not a replacement metric.
Average joes can ask skilled friend to setup their node and it will run maintenance free for 10 years. Or it can get disqualified in a month because ISP is having outages for 2 hours daily for no fault of a skilled friend.
My point is if you want to vet nodes — vet nodes. As it is done today. Not operators education, skills, credentials, or medical history.
That’s not what I said. I did not say “scrap the node”. Just require by ToS for operator to inform the satellite to reset vetting state when underlying platform changes, because it’s not possible to completely eliminate cheating - you can move node to another hypervisor in the other datacenter and nobody will notice from outside. Node will still get egress but no new data until it proves it’s still can run reliably. By running reliably.
Im almost certain amazon doesnt store small files in there datacenter like storj does, But They do store many files around the world they dont store everything in a single datacenter it must be spead equally around the world to get the fastest speed anywhere you go. Just because its not stored the exact same way doesnt mean its not decentralized right? Being able to access a file if one datacenter goes down in a location it was also stored at.
That’s what I would actually suggest. Have a vetting process where over the first, let say, 6 months of using a new wallet address, or likely also reusing a wallet after a period of no payment, all nodes using this wallet are considered as gradually vetting, slowly receiving more and more traffic. Can you point out the ridiculeness of this idea?
My unsubstantiated belief is that correlation will be strong enough to be primary predictor of node stability. Unsubstantatied because on Storj Inc. has the data to test this hypothesis.
That would actually be useful. Vet whether a person can survive a heated debate on the forum without going postal.
So people who are honest would have to keep their old hardware, not being able to upgrade to SSDs or adding RAM, failing races because of high latency and filewalkers, whereas most traffic would go to dishonest people who actually have flexibility in tuning up hardware of their systems.
I am not sure this is a desired outcome either.
Wishful thinking. Each AWS S3 bucket is tied to a specific region. If you want geo-redundancy, you do it on your own. Hint: AWS has lost files in the past. If you want low latency, you pay additional fees for Cloudfront.
2 Likes
Interesting that is good to know that I cant trust AWS, I just figured since when netflix used to use the service from amazon the data was spread around the world for the lowest latency.
They don’t pose a real threat to data durability. You can lose 1000 subnets and still fulfill the eleven 9’s of durability promise. See below for calculation of the scenario if Russia would go offline.
That’s the wrong question to ask. Normal home computers are bad systems to use for Storj. But home NASes or home servers are great devices and will often have much more free space. I started when I had 15TB of free space and assigned 10TB to Storj from day one. Calculating with 550gb for ever node is just super unrealistic.
This is incorrect. The original goal was to ensure that no more than 5% of pieces of any segment would be stored on unvetted nodes. It still ensures that just fine. The current side effects are bad regardless, but there is still a good reason for file durability to keep running it to ensure that original goal. They’re already working on tuning this system though, so hopefully the bad side effects will get fixed too.
Because they promise their customers eleven 9’s of durability. The percentages you listed only go up to five positions, which means they are completely useless to verify if they can keep that promise. Furthermore, segment availability drops over time due to nodes going offline or dying. You assumed there will always be 80 pieces per segment, but those values have dropped as low as 50 before repair kicks in.
Going back to the Russia going offline case, we can calculate for any x pieces of availability what the chances are that at least x-28 pieces end up on Russian nodes. Wolfram Alpha can help us plot this (honestly, people should use it more. It’s so good at this stuff):
As you can see, with 50 pieces available the scenario of Russia going offline would lead to less than six 9’s of durability. In fact to still be able to promise eleven 9’s of durability, they would have to ensure at least 60 pieces are available for every segment. The lowest availability tends to be around 54 when I last looked, so in my opinion Storj Labs can’t currently promise eleven 9’s or durability should Russia go offline.
I’m not convinced. This would result in residential ISP connections being bundled together as well. You may even end up with MORE data if they would do this.
It seems that only provides six 9’s of durability though.
1 Like
I was countering the claim that the process of so-called incubation was supposed to somehow affect some reputation factor. If the node receives data, that means it was deemed by a satellite as reputable enough. If this ratio is the outcome of the 5% rule designed to provide durability guarantees, then that’s just math.
Yeah, that’s kind of the point. Let say, n=30, k=20 would probably be pretty decent if these n=30 were Amazon data centers.
Of course it is! And that was kind of the point. But assuming most people have a NAS at home with more than that is even more unrealistic. Most people just use google drive or amazon for cloud storage. How many people do you know that have a NAS at home? Between all my family and friends, some of which are gamers, programmers etc… I don’t know of a single one who runs a home NAS. I even offer them free cloud storage just to encourage them to ditch the monopolies and keep their data a little more private but very few use it. Most would rather pay google simply to not need to have yet another account, password and web address to remember. To be honest though, I’m not really sure which side your arguing by pointing that out… so I’ll just leave it there.
1 Like
Perhaps may incentive to use a separate ones for each node (and have a headache to manage them of course). Also SNO who uses a deposit address of the exchange would be in permanent vetting process if they scale.
Perhaps it could balance itself.
I have used a self made NAS a long time ago, until I lost 1/6 of my data. Only small amount did not have a copy though, so I restored almost all, but some scanned old black-white films (I was a photographer in my childhood) were lost. I still has originals though, so I may scan them again.
However, this forced me to search ways to store data reliable and not only in my home on the one server. This is where it started 
So in the beginning I run my first bittorrent node on the router and stored data on connected external HDD (actually it was a normal IDE HDD in the USB box with the fan), until this box is died and killed this HDD.
Then I found Storj, on that time I already built my game server, my family was able to game on it directly or using remote devices (like an old weak laptop, but in the convenient place everywhere, include home yard). It also used as a hypervisor for VMs in my projects. It has had a lot of ( 
) unused disks, because I found a way how to backup my data reliable (some were also written on DVDs), so these disks become almost not used. And now that space is used by Storj.
2 Likes
So you’re actually kind of overcommitting?
Yep, might be. But even given the average knowledge of node operators, 80 / 29 might be a little bit exaggerated. Although, it improves the network speed quite a bit I suppose.
- Agree on this, so considering whales are most often more professional and the fact 3-5 pieces of the 51 covers the risk. I would agree, no to be bothering too much about it…
- I’m especially interested in why those other 46-48 pieces exist, since data completeness <96% leads to disqualification I would consider only uptime being an explanation…
This is just cutting some corners. I mean, why should it be done as the way as it is today. Although I’m not against the vetting process per se, other factors can be involved like reputation (first node vetting 1000 audits, 2nd 500, 4th 250, 5th 125; only considering the currently vetted satelites from the same SNO, … ). And if you also relate it to the amount of held currently amount of held money (as: more held money = shorter vetting process). Both also make incubation at scale more cumbersome.
Exactly, same thing I thought. Especially small SNO’s will suffer from it. So, the tinkerer who especially contributes to the dispersed network STORJ wants to build.
1 Like
I know quite a few. But I also don’t find anecdotal evidence very compelling. Neither yours nor mine.
That estimates the US NAS market at 27 billion (2022) and expected to grow to 117 billion ten years later. That’s about $80 per person in the US. Sure a lot of that would be small businesses, but that still accounts for a whole lot of home systems as well. The thing is, normal home PC’s simply aren’t viable, because they’re inefficient, unless for some reason you leave them on all day anyway (which would be stupid unless you have a very good reason).
Besides, running a node is something only the more techy people would be interested in anyway. And you can bet that market penetration of NAS systems or home servers among that crowd is a lot higher too.
You can’t really prevent that if you share the same storage space between several nodes. I have 5 nodes on the same SSD accelerated array as well and they all report all the free space. It’s just what the node software does, unless you divide up the free space in the allocation. Which I don’t do, because I expand when the space fills up anyway and I don’t want to stop a node from filling further if one of the fills up before the others.
Did you see the calculations in my previous post? I think these numbers are warranted and required. I’d love to hear your thoughts after reading that.
wich i proposed here, with voting
@bre is that the living discussion you are seaching for, to rework held?
Yeah, the basis for this idea is: the not your keys, not your money rule is an approximation of the actual owner of the setup, and the fact that—at least with L1—minimal payouts would stop people from having multiple addresses. The latter is broken with L2 payments, but with some adjustment it could probably work… not my job to finetine these ideas.
This case falters in some ways:
- First, they’re committing this for the whole collection of files, not only for files which have left only fifty RS-pieces.
- Your calculation is incorrect concerning chances, because you’re only considering chances on Russion nodes (and missing out on the non-Russion nodes):
binompdf(n,p,s) = nCr(n, s)*p^s*(1-p)^(n-s) - Reeds-Solomon’s N/K’s are 80/29 instead of 80/28.
- The question is not whether there are 29 pieces in Russia, but wheter there are no more than 29 left in the remainder of the world; so the cumulative aspect is being missing in my opinion (CDF instead of PDF).
So, I did it in Excel, because Wolframalpha isn’t that keen on distributions with variables:
Pieces left at moment of cutt-off (N) Optimistic chance <29 outside Russia Your calculation Realistic chance < 29 outside Russia Average retrievability, with N as repair threshold assuming equal distribution 80 6,65E-27 3,13E-25 5,06E-21 5,06E-21 79 3,32E-26 1,56E-24 1,89E-20 1,20E-20 78 1,64E-25 7,70E-24 7,04E-20 3,15E-20 77 8,08E-25 3,78E-23 2,60E-19 8,86E-20 76 3,94E-24 1,84E-22 9,53E-19 2,62E-19 75 1,91E-23 8,91E-22 3,47E-18 7,96E-19 74 9,19E-23 4,27E-21 1,25E-17 2,47E-18 73 4,38E-22 2,03E-20 4,49E-17 7,77E-18 72 2,07E-21 9,60E-20 1,59E-16 2,46E-17 71 9,73E-21 4,49E-19 5,62E-16 7,84E-17 70 4,52E-20 2,08E-18 1,96E-15 2,50E-16 69 2,08E-19 9,56E-18 6,79E-15 7,95E-16 68 9,51E-19 4,35E-17 2,33E-14 2,52E-15 67 4,30E-18 1,96E-16 7,90E-14 7,98E-15 66 1,92E-17 8,73E-16 2,65E-13 2,51E-14 65 8,50E-17 3,85E-15 8,81E-13 7,87E-14 64 3,72E-16 1,68E-14 2,90E-12 2,44E-13 63 1,61E-15 7,22E-14 9,41E-12 7,54E-13 62 6,86E-15 3,07E-13 3,02E-11 2,30E-12 61 2,89E-14 1,29E-12 9,57E-11 6,97E-12 60 1,20E-13 5,34E-12 2,99E-10 2,09E-11 59 4,94E-13 2,18E-11 9,23E-10 6,19E-11 58 2,00E-12 8,78E-11 2,81E-09 1,81E-10 57 7,95E-12 3,48E-10 8,40E-09 5,24E-10 56 3,11E-11 1,35E-09 2,48E-08 1,49E-09 55 1,20E-10 5,18E-09 7,18E-08 4,20E-09 54 4,54E-10 1,95E-08 2,04E-07 1,16E-08 53 1,69E-09 7,18E-08 5,71E-07 3,16E-08 52 6,13E-09 2,59E-07 1,57E-06 8,45E-08 51 2,19E-08 9,16E-07 4,20E-06 2,22E-07 50 7,62E-08 3,16E-06 1,10E-05 5,70E-07 49 2,59E-07 1,07E-05 2,83E-05 1,44E-06 48 8,60E-07 3,50E-05 7,08E-05 3,54E-06 47 2,78E-06 1,12E-04 1,73E-04 8,51E-06 46 8,71E-06 3,45E-04 4,09E-04 2,00E-05 45 2,65E-05 1,03E-03 9,41E-04 4,55E-05 44 7,79E-05 2,99E-03 2,09E-03 1,01E-04 43 2,21E-04 8,33E-03 4,51E-03 2,17E-04 42 6,04E-04 2,22E-02 9,34E-03 4,51E-04 41 1,58E-03 5,68E-02 1,86E-02 9,04E-04 40 3,95E-03 1,38E-01 3,55E-02 1,75E-03 39 9,40E-03 3,16E-01 6,45E-02 3,24E-03 38 2,12E-02 6,83E-01 1,12E-01 5,76E-03 37 4,49E-02 1,38E+00 1,83E-01 9,79E-03 36 8,91E-02 2,56E+00 2,82E-01 1,58E-02 35 1,64E-01 4,36E+00 4,09E-01 2,44E-02 34 2,80E-01 6,68E+00 5,55E-01 3,57E-02 33 4,35E-01 9,02E+00 7,03E-01 4,96E-02 32 6,16E-01 1,05E+01 8,32E-01 6,56E-02 31 7,89E-01 1,00E+01 9,25E-01 8,28E-02 30 9,17E-01 7,42E+00 9,76E-01 1,00E-01 29 9,83E-01 3,79E+00 9,96E-01 1,18E-01 28 1,00E+00 1,00E+00 1,00E+0 1,34E-01
NB: In extremis, your chance is going over 1000%
Also my calculation is overly optimistic, so I added a realistic chance in the one but last column: I assumed 95% chance of retrievability due to factors like data loss and downtime.
So the good news is that the bare chance is better than your calculation; the bad news is that the realistic chance is even worse.
I don’t know the actual repair threshold, as I recalled it was 54. The fine news is, that there is a certain amount of pieces below 11 9’s theshold at the moment of the cut-off of Russia. But we don’t know whether that makes the promise of 11 9’s overall impossible. In order to have a clue, we need an additional column in here: the fraction of pieces with so many pieces left as stated in column 1. If I assume an equal distribution (which is not likely the case…) than 60 existing pieces should be the repair threshold, which is 60*0.95=57 responses on an audit. So that’s very close to the 54 I recalled, but probably overly pessimistic (as I assume, the distribution is very much skewed to 80 available pieces).
BTW: They claim a 99.95% availability, and a 11 9’s durability, but not stating on which time frame and under what conditions. I mean just dropping the bomb on western-Europe would probably invalidate this for almost every cloud storage provider.
So I wish, STORJ gave us insight in:
- The distribution of responses per audit (so, how many nodes respond to an audit of a single piece).
- The distribution of online nodes (what’t the average online rate).
These figures would help us, to enlighten this case on how dangerous a cut-off of Russia is; or how dangerous some whales are in the entire network (what statistical actually is the same thing, but on a different scale and time frame).
1 Like