Ah, I didn’t read the “external” part.
They would use nest to 30W, which seems reasonable…
actually you will receive $6.46 held amount plus what it is earned while running, it will be likely less than $20, but in total you will receive more than $20.
ok. I didn’t know the node would still run as usual.
Anyway, the math doesn’t seem good. If the node decreases linearly to zero size during the month, I should expect to receive 10 (plus 6.46), not 20. Also, for sure I will not receive anything for repair upload during that month (would amount to 66 if that was the case), so let’s say 8-9 (plus 6.46) would be more realistic.
Still less than 20…
You would for repair egress (which is download in storj terminology). There is no reason for that to change. You still have the data on a healthy node. So repair will still use your node as source as long as it has the data. It’s still less than what you would make if you kept running is normally, which is indeed an issue.
yep, you should be right. My node would still do the “usual” egress repair while doing the massive egress to other nodes (which I would also call “egress repair”, thus the confusion. I’m probably wrong on my name calling).
So, 10 + 6.46, still less than 20, still 25 Mb/s upload for a whole month.
Ahh, I see. Well, just for some context. This is quite different traffic. Egress repair is the satellite (repair worker) downloading good pieces from your node in order to recreate lost pieces on other nodes. This download transfers data to the repair worker. Graceful exit egress is just your node transferring existing pieces directly to another node. So no “repair” actually takes place, it’s more just a data migration.
You can always make it seem the SNO is not loosing too much money by taking just bit by bit from him.
The reality is that you’re taking money from him. Is it enough to make a difference?
I would rephrase what I said:
old: “try to explain a new SNO that the promised 1.5$/20$ will only be effective in 1 or 2 years”
new: “try to explain a new SNO that the money being taken away from him is not enough for him to feel the difference when he looks back in 5 years.”
I see your issue, but what do you propose? Repair is a pretty heavy cost for Storj. And you’ve said yourself that there is not enough incentive to run graceful exit. How do you suggest to resolve this? Keeping in mind that my suggestion would not even cover the repair costs, because it only accounts for costs paid to node operators for repair egress and not the significant egress cost for the repair workers.
1 Like
Have some kind of distributed repair where nodes can do the repair for cheaper and then satellite just checks it or something. I do not now how realistic that would be.
1 Like
Probably possible… might not be easy though. Satellites would have to still coordinate repair and then audit all pieces afterwards. You’d probably have to pay the node for doing the repair work as this will have considerably more impact on system resources than the current node operation does. You suddenly need to do RS decoding and encoding, which impacts CPU. Plus you have extra egress for uploading to other new nodes. And this is in addition to egress still happening for the source nodes for repair.
Then for the audit afterwards, the satellite could probably just audit a stripe, which would impose significantly lower bandwidth impact, but is a large amount of audits that need to happen. Furthermore, audit currently only checks whether the RS decoding works. The node doing the repair could upload garbage data correctly RS encoded and it would pass that test. And comparing to a segment hash isn’t possible if you only audit a stripe. In theory you could audit the entire segment, but that would mean you have to pay nodes 3x for egress. Once for sourcing good pieces, once for uploading new piece and once for downloading the new pieces for audit.
That why I propose to moove repear workesr to node operators, it can be special nodes with contracts, it will reduse this costs very much, also as audit.
See my previous post, haha.
To be honest, if this were an optional type of node people could run, you could probably pay less than the current $10 for egress to those nodes. And people could decide whether they have the resources and find it worth it. I probably have CPU to spare on a few systems and they technically don’t have to be online all the time either as there is no permanent storage. And I have plenty of bandwidth to spend on this too. Furthermore these repair workers could run on cheap VPS’s as well as there is no high storage requirement. I’d definitely love to give something like that a try.
Just have to find a good solution to auditing the new pieces without having to download the whole segment again. Just thinking out loud… the satellite could audit a stripe before repair is distributed to repair nodes, store the hash for that stripe and audit that same stripe again after repair. This would just impose 2x stripe downloads, which are fairly insignificant.
2 Likes
I thin as it is High egress work, it cold be even 5$ per tb.
I have intel I7-12700 for this work doing almost nothing.
Yep, but you’d still end up with a cost of $15 per TB total if we disregard the cost of running the additional audits. Not all of that cost has to be covered by held amount, it can be covered by margin on storage as well. So the balance should be to have a reasonable held amount to incentivize node operators to run graceful exit and cover the rest with storage pay margin (eventually, subsidized for now is fine).
After talking through it, this may actually be really interesting. @john what do you think?
Totaly agree with you. For today i think it is something 10$ per tb to operayor and 20$ per tb for Repear server at Hetzner
1 Like
Well, I guess I don’t have a good solution… I just pointed out that the current solution is no solution…
Your’s is a good solution for a SNO that plans to run a node for a certain period and then exit. Not good when you start with no intention of leaving, because it’s money you will never get back. Your node will only stop when your disk crashes.
Maybe the held amount (10$/TB) could be returned when you’ve proved to the network that you are resilient and take the best technical care of your nodes in order to not let them crash by accident. Let’s say 3 years? 5 years? Not the whole amount in one go. You only get back the amount that has been held for 3 (5?) years (if your node has grown 1 TB last month, you will not get 10$ back for that TB, only in 3 (5?) years for that TB). After 3 (5?) years, nobody that resilient, and already making substantial money on the nodes (hopefully), would exit just because they got back the held amount.
Obviously, this would not make sure to the network that all repair is paid for, which is your aim (taking into account only the repair traffic). A node could always crash or a SNO could die or whatever. So, maybe 11$/TB? 12$/TB?
This way, if you start a node just for “experimenting” and you’re not serious about it, you have a good incentive to exit gracefully, because the held amount is substantial. If you don’t exit gracefully, your exit is paid for.
If you’re serious and plan to be in the network indefinitely, you won’t feel that the network is taking money away from you. It might be held for quite some time, but if you behave, you know it’s yours.
1 Like
I like that. That gives Storj plenty of time to make money on that data to cover any required repair costs. Shouldn’t be more than 3 years probably, since expected good lifetime of an HDD is about 5 years. You don’t want to get near that. So basically you well get any held amount back 3 years later if your node is still running fine.
That’s awesome!
But I wonder if that won’t leave you with the same situation of not having enough incentive to do graceful exit. I guess at that point the cost is kind of covered by the storage and egress margins (eventually). But it would still be a lot better for everyone if the network doesn’t get more costs than needed.
1 Like
I like the idea that if you have 10tb node, held amount should rise til 10tb x Y$ that it cover repear process, and after 3y can be returned, at least biggest part of it. But repear process shold be more cost effective than now, that it would be possible to put Y as low as possible.
1 Like
Well, not at the moment… remember why you started this thread? 
well, I think when your disk reaches 5 years, maybe you should move your node into a new one. You’ve already earned more than enough to buy a new one. That’s one of the SNO jobs, to make sure the nodes are technically sound. You can start another node on the old disk and see if you can extract 2 more years from it…
That is exactly my point with a “very delayed” return of held amount. Nobody that resilient will exit (gracefully or not) just because he feels like doing something else. You have a large node (if no growth restrictions were applied) with a substantial income. You proved you’re serious about it. You’re not exiting on purpose (maybe you’re pushed out by a disk crash). Of course there will be exceptions, but as long as it’s just exceptions…
And I did propose 11$ or 12$ of held amount per TB, but you only get 10$ back. The rest, hopefully, will cover ungraceful exits. I believe there aren’t many ungraceful exits from long-term resilient SNOs (!?)… maybe you have data on it…
I kind of think, not in my best interest, that 5 years are better than 3. I didn’t like your disk argument to justify the 3 year period.
Maybe we can settle for 4? 