Hi, @Dimitar , did you find running storj worthwhile?
I’ve a system running 24/7 , couldn’t hurt to add a hdd and setup storj.
Trying to roi on some storage before we go live.
1 Like
Look at this analysis:
running hardware dedicated only for storj isn’t easy…
mainly because you run into the issue of disk capacity… if you use a 6tb hdd it will take a year to fill… so the ROI really starts when you are a year in, if you have a smooth ride.
with a 12TB it might at what we have been seeing for the last long while… would then take 2 years to fill… so really thats the main issue.
also that the internet, and the hardware prices, the monitoring and troubleshooting when stuff goes wrong.
but if you can keep the nodes alive, and don’t waste to much hardware or time in running storj, then it can be profitable… but i think the main key to profit from storj is to use systems that have primary purposes, and then run storj as a secondary bonus.
since it doesn’t really take a ton of resources.
if we do that math on this example
DC CZ there are 2 nodes on Dell R210 29€ month and imagining 12tb hdd for eachso a max monthly earnings of 24x3$ lets just underestimate.
so 72$ after 2 years of operation… which which the 1st year they will be operating at a loss.
and tho i’m sure they could perform okay during the first year, i doubt it … so underestimating… by calling it … well it will be lucky to cover 2 months operational costs… so ill just call it zero.so first year 0 profit and expenses is like 600-720€
then 2nd year they will start to cover their operational costs.
as it being about half the max earnings…and at end of year should earn 72$.
so thats an avg of like 20$ each month, so for the full 2nd year would be 12x20 so
240$…so two years in and capacity just filled and we are still 400€ in the red.
so unless we add more capacity the 3rd year will pass and we will still be in the red…
but not by much… the only way to offset that would be to store past 12TB for each node.if we calculate both options… 12tb pr node max and going to 18tb on year 3
that would put us starting out at the max which is 72$ pr month and so lets call that 40$ profits pr month, so a yearly profit of 480$ and having paid 240$ last year of the 600€
which basically equals out with the costs of year one… so during year end of year 3 i would expect a setup such as that to make profits…for the dual 18 / infinite capacity… so adding 2x6TB for both nodes x 3$ pr TB making it
36$ extra earnings pr month,and using 50% of end of year earnings as the avg, again assuming a linear progression of ingress.
ergo 18$ avg earned extra pr month over the year. so 210$ or whatever
so that would basically be the earnings after 3 years of operation… a couple of hundred $
15$ overhead pr node is a killer for your ROI
sorry if this is kinda bleak, but just trying to work with semi realistic numbers.
the earnings have also been under estimated, so might be a lot better…
but this i would say one has a pretty good chance of earning.
even with that much overhead.
Privacy. Security. Freedom
3 Likes
Don’t worry about a bleak outlook, I wanted the truth not sugar coating, thanks.
I’m running chia node with same intent, so node needs to stay up anyway, and with multiple hdd on chia, I see little extra cost involved other than the hdd’s.
I’ll probably throw 1 drive at it and see how it goes.
Thanks
1 Like
Seems the issues described there are mostly blockchain specific. Should be easier with SAFE and DBCs.
There are still cases where we would want all inputs to be private though. Depending on the use case there’s fully homomorphic encryption, functional encryption and secure multi-party computation that can be used by themselves or in combination.
Here’s a blog post describing some basics of these methods.
https://www.esat.kuleuven.be/cosic/blog/the-three-musketeers-of-secure-computation-mpc-fhe-and-fe/
If we can assume groups of elders are not colluding, we can get interesting new ways these can be used on SAFE. Should be a fruitful avenue of research once we get compute support and to some extent even before then.
2 Likes
As there’s no transaction history it should be possible to hide inputs to a DBC by masking each input with an upstream transaction.
3 Likes
There’s really two types of inputs. One is the inputs to a DBC, the other is inputs to a function/smart contract that runs on nodes. A function could for example be a function that takes two input values and returns true/false and if it returns true something happens to a DBC or whatever.
There are cases where you don’t want nodes to be able to see the inputs to the function, only the output and there are also cases where you don’t want nodes to see either the input or the output, but instead want the output returned to one or more clients who have decryption keys and will decrypt the output and decide what to do with it.
2 Likes
Yeah this does bring certain limitations. If the elders can steal information from some computation that’s split between all of them in cases where they communicate with each other so all of them know each part, then we can’t really know if they’re using this information for something or even that they got this information. Such cases should probably run on each client involved insetad.
1 Like
Is Elder collaboration really an issue? Because if is an issue here isn’t this a more general problem?
I think it remains to be seen, but it may not be an issue for a lot of cases.
2 Likes
Yep, good point, for cases where the result can be used like that. I’m not sure how many uses that would be an issue for still, but probably true for some.
3 Likes
Probably not a big issue, but I was thinking specifically of cases such as you some secret S, divided into, say, four parts A,B,C,D, where four elders each had one part and where knowing all parts of the secret could divulge something like some secret trade information. If this was the case, a bunch of elder could share such information in a chat group with no repercussions.
There’s also the case of functional encryption. Functional encryption could probably be quite useful for smart contracts in that you have encrypted inputs to a function, but the output is decrypted, such that some DBC transfer could be done if some condition was true, but the input data wouldn’t be seen by the nodes. There’s also varieties where the function itself is encrypted, so the nodes would just run some smart contract/function and know that it returns true or false, but wouldn’t know the input or what the actual function. This could be used to create completely secret anonymous smart contracts, the nodes executing the smart contract would see neither inputs, nor what the smart contract did, all they’d know is if it returns true or false, whether to transfer some DBC or not.
The potential issue with functional encryption is that the way it would work is that a group of nodes (elders) each would have a part of a master private key (their BLS key perhaps, if that works). Then what you do is you have the group derive a new private(decryption) key specific to the function you want to calculate and this private key would be shared among the nodes and can only be used to decrypt the output of the function. If, however, the nodes found a way to communicate out of band, they could share with each other the parts of the master private key and use that to decrypt the input.
A solution to this would be if instead of only creating a private (decryption) key corresponding to each function that is to be evaluation, it would also generate a public (encryption) key corresponding to each function. In this case each user would encrypt their data with a public key meant only encryption data for one specific function and where the encrypted data could only be decrypted through that specific function. Probably overly paranoid for most use cases, but might be a nice addition. If the BLS key could be used for this though, it might not be neccesary to have a public key for each function since decrypting the data would require each elder to share their parts of their BLS private key with each other and unless all elders was owned by a single entity, this would mean that no elder would want to share their share of the private key with the others as the other elders could use that to screw them over.
1 Like
My spider sense thinks BTC will see see another 50% dump from today. Posting this here to keep myself honest about what I was thinking when it goes up 50% and fomo starts to creep in…
5 Likes
Bitcoin at $32,800 sitting up in bed now and on its second bowl of chicken soup.
Doctors still keeping a close eye on it though.
4 Likes
The patient showed a slight improvement today. Doctors are said to be cautiously optimistic.
2 Likes
Who was it on here was punting Haven, XHV?
The idea may be great but the performance is crap. Thankfully I only bought ~$50 worth.
Well I suppose it could be worse news…
I should count myself lucky, its only a fraction of what I lost in Altilly…
Thanks for the update.
Interesting. How could we roll back a safe network? Would we ever want to?
I’d guess the only way would be a daily snapshot, but we’re not blockchain so I’m guessing it’s impossible.
1 Like
Burning could still be ok assuming that all maidsafecoins at an address wouldn’t have to be burned at once, then people could transfer only the maidsafecoins they plan to use or sell as needed and the rest would be protected by the bitcoin blockchain until needed.
In theory you could make a snapshot and start from that even if they’ve already been burned. Use the addresses used to send to the burn address and check what the balance was prior to sending to the burn address.
Binance getting some heat from all sides.
The UK and now Thailand and Cayman.
2 Likes