Doesn’t matter, we’re talking about orders of magnitude differences here. You can average it out over the range all you want, but the lowest reliability is going to mostly determine the average.
This is incorrect. My calculation is not for exactly the amount of Russian pieces that lead to data loss, but that amount or more. Meaning that it doesn’t matter if the other pieces are also Russian or not. In that case the second part would be equal to *1 and might as well be left out, which I did.
Correct, but when 29 pieces are left there is still no data loss. Hence I calculate with when 28 or fewer pieces are left.
It isn’t. See my response to your second point.
Well you’re right about that, but I’m still not sure where the flaw in my thinking is. Curious.
Well that will surely be the case for newer data. But on sufficiently old data, I think the equal distribution is a fairly good estimation. And most data is old. The problem is that they’re still several orders of magnitude away from eleven 9’s. It’s going to be near impossible to compensate for that with favorable distribution. In order for the 2,04E-07 chance for 54 pieces to not be a problem overall, it would have to represent 1/10000 pieces. And that’s assuming the very rest of the range is rock solid (which we know it isn’t and there are many more below the durability threshold).
I don’t think it solves the problem.
Either way, despite our different outcomes, I think your results still make my point that in order to be able to fulfill the promise of eleven 9’s, these settings for their RS implementation are required and even not sufficient in the case of Russia going offline.
It’s industry standard to measure durability on a per year basis. But again, that doesn’t help them much. Even if Storj was 10 years old, that would get them 1 order of magnitude if you spread it out over those 10 years. Which clearly isn’t enough. We’re also not talking about dropping a bomb on western-Europe. We’re talking about a much more realistic scenario of Russia being cut off the internet.
That I agree with 100%.
Though I’m certain they are doing a lot of these calculations in house as well. It would be nice to have some insight in them.
One last note. We’re calculating with the assumption that this is the only risk factor. But if Russia going offline would put them right on the line of eleven 9’s, they’re still in trouble, because the other native risk factors in the network are still in play as well. They would have to also have a solid additional margin for that risk.
It’s for the benefit of SNOs if Storj can lower the redundancy, because there would be more money to play with and it could stop payouts from lowering further. So when those suggestions pop up, it’s good to know why they couldn’t just lower those numbers given the promises they are making to customers. What effects us as SNOs and what impacts customers is tightly related. If we want to make a good argument for one side, it would be helpful if we consider the consequences on the other side.
Furthermore, additional transparency leads to enabling outside resources to contribute to possible solutions. Isn’t that kind of the whole idea of open source? Taking the contributions where you can get them, no matter the source?
I don’t think that’s what we’ve been discussing here. But sure, the payout discussions have veered into that. I’ve mostly remained silent on the broader business scope though as I am indeed not qualified to respond to that. However, when the scope is limited to something like unit economics, it becomes easier to join in and make suggestions.
I don’t disagree, but it can’t hurt to ask, right? If they see value in sharing this kind of info, because it might enable external resources to think along and provide solutions and new information. They can share it. It’s up to them. I don’t think anyone is demanding. Chill dude.
If lawyers are watching… no we’re not! 
But yeah, I agree with everything else @JWvdV says there.
That exception is the whole ballgame, my friend. 
So… then it’s good to show how they are related. Is it not? We can have a more informed discussion that way and prevent baseless suggestions of just lowering the redundancy that wouldn’t be viable anyway.
Then shouldn’t you welcome the hard numbers shared here? This isn’t bickering right now. It’s analyzing and informing.
That is nothing to be proud of. That kind of secrecy gets people who rely on a company for their livelihood screwed over. It allows companies to pull the hood over everyones head and screw over employees, contractors, suppliers, customers and everyone who depends on them. Transparency is important and actually helpful for the company too.
If you’ve been corrected on this and keep saying it, it seems you aren’t listening.
Storj is already really transparent. And that transparency works both ways. The point is that they are really open to informed community input, even when they haven’t requested that input themselves. If I look through the feature requests I’ve posted, I can see that most of them have been implemented. Often with an informative back and forth between Storj and the community in the process. This includes things they never asked for, like my suggestion to stabilize reputation scores. Tuning audit scoring Refining audit containment: Refining Audit Containment to Prevent Node Disqualification for Being Temporarily Unresponsive Checking storage path availability: Make the node crash with a fatal error if the storage path becomes unavailable Adding suspension scores to the API and dashboard: Report audit suspension scores back to node databases, API, and dashboard And many more that aren’t in the suggestions area, but posted elsewhere. With this kind of back and forth being seemingly very productive for both sides, why would we not discuss these things?