Proposed changes to the method how Held Amount is collected

+1 to the idea to return the held amount only on GE to cover repair costs. There is no reason to pay the held amount back early.

I think that since we are talking about money here, one should not just rely on trust that the node operator will not shut down the node after x months after all.

1 Like

But a new disk is likely to cost $50-$100+ whereas withheld will in all likelyhood cost you less than $20 to write off and use that storage instead. Even if Storj retain all withheld it still makes no economic sense not to just delete a node instead of buying more storage.

1 Like

but its not the case, and in large style…

Hardware can still die - even at scale. The ovh datacenter fire is illustrative of this.
https://www.datacenterdynamics.com/en/opinions/ovhclouds-data-center-fire-one-year-on-what-do-we-know/ It may not be so common place as a drive or motherboard failure but they still do happen.

Yes. But its not only about economy. Its about security of the node network.
If it is an large scale attac of an big enemy cloudcenter, i would host massive nodes for storj, including incubating and held evading behavior and then boom. Al nodes down, storj struggles with repair cost/ segments lost and goes out of bussines

i thought about the issue with held amount a bit in the past.

my eventual conclusion was that held amount needs to mirror the data stored.

so lets make it fairly easy then…

egress during GE is unpaid, so i argue that a reasonable amount would be the TB egress rate.

well the egress rates is a bit annoying to easily calculate for all sats, so i will a rough estimate.

there are how many sats now 3 or 4 sats?
did GE for 3 of mine… so don’t really know lol… sorry
i think its 4

at 5, 6 and 10 $ pr TB egress = ill call that a 7$ pr TB egress avg

thus a 10TB node would have 70$ in minimum held amount… until GE
because else why bother with GE.

uploading 10TB is a massive challenge for most.
there is no loss to Storj for this… also less repair costs because people would care more.

i would also suggest that held amount is always collected, until the minimum is meet.
so as a node grows, the reward for doing the GE also grows.

this is the only sensible way i’ve been able to come up with.

ofc this would be on a satellite basis and based on the individual sat egress rate and the amount of data stored by the storagenode for that satellite.

just trying to show that the numbers would be in line with what i would consider reasonable.
when considering how much load a GE causes.

I don’t like the whole idea of “held amount”.

Because if this is money I I have already earned but storj owes to me indefinitely to punish me if I fail to GE — then:

  • storj should be paying me interest on that money. Why should I give storj free loan?
  • I will not GE out of spite. (Ah you are holding my earnings expecting me to fail to ge? I’ll make sure to meet your expectations)

Instead, this should be framed as a “reward for GE”, that would be proportional to the nodes’s value for the network (age, size, uptime/audit metrics, etc) and normalized to nodes past earnings. .

I.e. people will be more likely to do GE for the reward, as opposed to under threat of punishment. Just a psychological subtlety.

quite easy to implement i think, used space is known by the sats, so “collect” for every 500mb filled 3.5$ from the payout.

is realy al data uploaded at GE? or just the pieces that would trigger the repair process?

SNOs! we have to build up an security amount for participating in the network!
To be save from harm trough exploiters and bankruptcy!
we just need to set the security reward for GE at x per stored tb!
you dont have to do anything, we set automaticaly :stuck_out_tongue_closed_eyes:

and then just adjust the held to the new system for every active node

today Held amount is working like punishment, when you are new and if hdd fails.
May be it better to account in payout price, and make like reword when you make GE successfully you will get additional some money.
for example people will get 1.45$ fot TB thay store all the time, then held amount will be accumulated all the time depending how much node store data. numbers are just for example no math was made. same thing with egress. This money should cut the repair work.

1 Like

Not all data, only the minimum enough to fulfill 80 pieces in the network to avoid repairs.

so it could be less than 7$/TB, also ok.

storj can do the math :grimacing:

thats why i propose the age (under certain months could be held free) and the filling to be used.

ofc it would be wellcomed if held was to cover unexpected failure, and storj woud add an good bonus for ge, but under certain circumstances, so it would not be exploited.

would appreciate an vote button at the bottom of the topic, is it possible?

@Alexey

people can vote, but you need to sketch out exactly what you are proposing, else what are we voting on.

we have been trying to get StorjLabs to change the held amount methodology for years now.
so i doubt anything will come of it.

So what is your question?

Tines,sno behavior and network change over time. Maybe the opinions at storj also?

Just another idea would be a certain amount held for your amount current data stored.
So for example: $3 per TB.

The pros:

  • It doesn’t matter whether you incubate your drive or something.
  • It’s really a fixed $/TB of repair, which would be the case at the point of failure.
  • You don’t incentive people with smaller nodes, compared to those with bigger nodes. Because held amount in the end is the same for 2x6TB node vs 1x12TB node when filled to the rim.

The cons:

  • It probably means that you won’t earn for at least the first two months a dime; this may also be true, at the moment you increase the size of your storage node.

For example if you have 1TB allocated, you will not be paid out till there’s $3 held if there’s also 1TB stored.
Since my nodes grow about 300-500GB/month, this would mean:

  • 1m: 300GB, 0.15TB average over the month stored: 0.15* $1.5 =$ 0.23 earned, 0.3*$3=$0.9 should be held > $0.23 is being held, no payout.
  • 2m: 600GB, 0.45TB average over the month stored: 0.451.5=$0.68 earned, 0.6$3=$1.8 should be held > $0.25+$0.68=$0.91 is being held, no payout.
  • 3m: 900GB, 0.75TB average over the month stored: 0.751.5=$1,13 earned, 0.9$3=$2.7 should be held > $0.91+$1,13=$2.04 is being held, no payout.
  • 4m: 1000GB, 0.97TB average over the month stored: 0.971.5=$1,45 earned, 1$3=$3 should be held > $2.04+$1.45=$3.49, of wich $3 is being held and $0.49 is being paid out.

I think it can be not from amount you allocate but from amount you have data. with example 3$ pet tb, if after first month you have 100gb that mean held amount will be 0.3$ from full payout.

1 Like

That’s exactly what I meant, see the example. Because allocation can be modified by the SNO, while stored data isn’t supposed to (and if, you’re going to be DQ’ed).

1 Like