Don’t be fooled by the high nodes numbers at €0. They’re mostly (1203) backup nodes. By the way, thanks to @Th3Van !
It is a free market, but nothing in this world is free. Someone might be donating resources today because they have a well-paying job, cheap electricity, free hardware and spare time. That is not the same as those resources being free. It only means nothing else is competing for them yet. And sooner or later, life will start competing for them.
Thus network priced on donated resources isn’t priced on anything stable. It is priced on conditions that cannot last. So there is no point being angry at it as it will, sooner or later, change.
better to prevent than to treat
Wise words.
And to that I would add that it is also not a business model to rely on free storage.
My view is that I will be running the nodes for free for a limited period of time in order to maximise the chances of the company pulling through this situation.
But I have no intent (and it would not be good for the company) to keep that up indefinitely.
EDIT: although the concept of “bidding wars” from SNOs is intriguing. Very much unlike the “communist model” alluded to earlier, it would be an interesting take on an even more free market…
The tax perspective here might be interesting for some. Per the short research I’ve done, in my jurisdiction, as long as this is considered a “donation”, I’d still have to pay taxes for the full amount as if I had not reduced the payout… which makes it a rather difficult choice for me, sorry.
But the moment Storj introduces traffic adjustments rules based on the custom payout rate, this becomes setting competitive prices on a marketplace and the situation is clear.
If Storj switches to a model where SNOs bid for used-space: they may need to drastically change their business. Because corporate customers will know if they park their data in any other S3 provider… there’s at least some consistent infrastructure behind it.
It’s hard enough to get them to choose Storj today: they’d probably flee if they heard it was turning into a bottom-of-the-barrel provider: where their data would be sent to the dodgiest (but cheapest) SNOs. Storj may have to become the “budget provider” of the industry. Forget about a premium service for Media & Entertainment users: their whole focus will turn into “be cheap”.
Which will attract the worst customers.
VOLUNTARY, Excellent @littleskunk - Imma give chew a raise! 
My 2 pesos,
You might want to use this as not just a backward partial payables reduction solution but a commitment to a FORWARD price setting. So you actually have something concrete in the cash flow plan, to show the judge. Otherwise the number is just cash meaningless if reorg isn’t accepted; a gamble I’m sure people here understand, but not entirely meaningful to the court.
You therefore get the commitment up-front and it can’t be considered just ancillary to re-organization, but will be a major part of it. Also entertaining the concept this way would be a major part of the weighted consideration the judge could apply; visa vie the going-concern the court will have in it’s contemplation.
So in the interim this config line could represent both previous and forward looking voluntary pledges/contractual obligations. OR inform the court on the 25th that we measured this much existing success with this data point. The savings were are already $X, provided voluntarily by the critical supply vendors (SNOs). Additionally we firmly anticipate that this will be a fully known statistic for the period ending this month. By virtue of this new tech we have just developed, going forward from 08/25 to the 31st, the subsequent month-end scheduling we will guaranteed to know the budgetary costs for every future first following payment due to our vendors. We will realize a further $X in cost reduction; and by virtue of existing voluntary these known vendor allotments we can verify a definitive short term COGS (this is extremely valuable to a bankruptcy judge, and any appointed monitor.) Thus we now know that cost savings will only go up for August (can’t be less than already voluntarily offered, right?) MOREOVER, $X COGS for SEPTEMBER are now resolved/known. Also, a pledged expiry date may be helpful in the implementation of a moving average concept; therefore, there is at this point another $Y pledged as FORWARD commitments.
P.S. I thank the Van and EVERYONE else for their immediate voluntary contributions, I think that’s commendable.
I will save some spittle for any the Hoc-tua guys who may poo-poo this quick solution.
In the future I suggest should be a developed ratio coded so that the network doesn’t degrade to $0-of-N in performance.
2 pesos,
Julio
P.S. Sorry if it got a little redundant up there, I can only enter 3 lines before scroll in post on this device.
I’m too lazy but, quickly
Forward is also more practical, in so many other ways. No last minute attempt to cheat, or screw up your budgeting, misunderstanding, complaints, etc.
Before this gets out of scope of your coding time allotment, make a decision soon so that nobody is harmed. And that the idea can be more fully communicated/broadcasted/approved to get out to the SNOs STAT.
1/2 peso,
Julio, P.A., B.A.; Retail Management.
This shouldn’t be forever. It might remain an option, but if it remains voluntary, then so be it.
On the other side, it will be easier for Storj to attract operators running nodes in rare locations. Fixed payout premiums cheap locations, so these locations have an oversupply of nodes which capture most traffic.
It could be, we have a small amount of nodes in Asia, Africa and Latin America. Usually because of internet connections there costs more.
You cannot be liable for tax on an amount of money you haven’t received.
It’d be different if you’d received it and then given it away, but that’s not how this is being proposed.
I don’t believe that for 2 reasons:
- The node selection works more as a load balancer. Currently it goes by success rate. Nodes with a high success rate will get more uploads. Nodes with a low success rate will get less uploads. This load balancer finds a healthy balance without overloading the successful nodes. If we would now factor in the payout rate there will be no dramatic change. It would allow the nodes to fine tune the amount of data they are getting. Nodes with high costs could try win by success rates. Nodes with low costs will get more data but without overloading them. It should still be nice and balanced just with performance and cost instead of just performance.
- I am one of the low cost nodes. Your argument is now that my node should have low performance. To some extend I would agree to that. But if we go by success rate my nodes will most of the time run as fast as yours. My feeling is there are other SNO in the network running multiple nodes on the same drive and I can outperform them very easy. So low cost nodes are not the elephant in the room…
Does this selection on cost basis already working or it is future stuff?
The answer to your question is it is future stuff. But I have to point out that answer will not chance even after the node selection gets changed.
Lets do a little thought experiment. I believe we all agree the final result is a node selection and some kind of abuse protection. In the short term we can ignore the abuse protection by just changing the node selection without telling anyone. It would benefit the nodes that signal a lower payout rate even with no benefit for themself. It gives us more time to fine tune the node selection. It gives us more time to develop an abuse protection. For that reason expect a clear yes only after the abuse protection is in place. There will be a time in which I will just doge your question kind of the way I did now 
Sounds fair?
Whatever you change: the priority has to remain speed-to-the-customer. If the satellite is tracking the fastest nodes… and you choose to use the cheapest-of-the-fastest… that’s fine. But if you start to degrade customer performance by using slow-but-cheap nodes then those customers will just leave.
We are able to simulate that. Marton has a nodescan tool that will upload a piece to each node and measure performance. With that data we can run any node selection as a simulation and calculate the impact on customer uploads.
yea but thats with current state of the nodes, if i knew that from this point the fastest AND cheapest nodes will win data, i would upgrade my connection to max tier to have maximum upload speeds (egress speed), so a node You will measure now with =0 price and rather low egress speed, would change to high speed in my case. (Because i would want to leverage the data inflow, and keeps it afterwards, having big upload (egress) looks like only way to win over other nodes, so its a race to heaven instead of race to bottom in performance, i would like this very much.)
Faster connection will make benefit only if today connection is fully used.