# Announcement: Changes to node payout rates as of December 1st 2023 (Open for comment) **URL:** \ **Category:** Announcements\ **Created:** [October 25, 2023, 10:02pm UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124 "2023-10-25T22:02:19Z")\ **Posts on this page:** 20\ **Page:** 8
**Author:** ![mattventura](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mattventura/32/7831_2.png) [@mattventura](https://forum.storj.io/u/mattventura)\ **Post date:** [October 28, 2023, 4:52pm UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/152 "2023-10-28T16:52:03Z")
> [@Pentium100](#): > > Uptime matters a lot more (Storj does not have such a thing as planned downtime), so does performance This is a problem I pointed out earlier in the thread. Node performance really _won’t_ matter now. You can just use async writes for everything so that you win ingress races. Even though you don’t get directly paid for ingress, you need data in order to get paid for storage or egress. When it comes time to egress, who cares? You only lose 6% if you lose every single race. The audit timeout is an astounding **5 minutes** (assuming the docs are still up to date) - that’s slow enough that you could use a tape drive! Also, I thought of another way to do this in a fair manner: for nodes that win more egress races, prioritize them for ingress. If performant nodes received more traffic than laggard nodes, it would incentivize performance, and encourage more serious SNOs to stay on the network. ---
**Author:** ![nyancodex](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/nyancodex/32/1129_2.png) [@nyancodex](https://forum.storj.io/u/nyancodex)\ **Post date:** [October 29, 2023, 3:26am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/153 "2023-10-29T03:26:00Z")
Guys, please stop discussing. There’s no point to waste your time any furthur. You accept or you leave. **Storj will do whatever they want/need to reach their goal of making this business model profitable by the end of 2023.** That’s their ultimate goal since last year, nothing else. Take a look at the old payout topic, all discussion is meaningless since they will execute their plan anyway. This is an announcement, an already decided thing. Good luck everybody. ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [October 29, 2023, 3:35am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/154 "2023-10-29T03:35:11Z")
> [@Pentium100](#): > > Running the node adds constraints to how I can use my server. Uptime matters a lot more (Storj does not have such a thing as planned downtime), so does performance (when the filewalker runs, but in general as well, for example during a zfs scrub). Also, once the node has taken some space, it is difficult and/or slow to make it give some of it back. I cannot back up the node to try something risky on the server (I can back up everything else and restore if I have a problem) - If node adds constraints and changes requirements for your server – your server is not suitable for running a node. Don’t run a node. - Storj uptime requirement are quite lax, nothing unusual there. - Filewalker has no effect on properly configured server. If it affects yours – your server is not suitable for running a node. Don’t run a node. - It’s very easy to rm -rf one of the nodes when you need space back. Also, plan ahead. - You should not be backing up node. It’s silly. redundancy is already built into the network. You don’t need to make another redundant layer here. It’s OK to lose some data. Also – why are you messing with your production server?! Do risky stuff in the VM in the test environment. > [@Pentium100](#): > > I also remember debates about whether to use RAID or not. It does not matter then, because people would already be using or not using RAID when they set up their nodes and not redo their servers just to fit the needs of Storj, right? I agree with you. That was bafflingly pointless debate. You either have raid already or not. that discussion was probably driven by people still confused about the project. ---
**Author:** ![penfold](https://storj.bcdn.literatehosting.com/letter_avatar/penfold/32/6_22734026db12803ebb3e059622ac3534.png) [@penfold](https://forum.storj.io/u/penfold)\ **Post date:** [October 29, 2023, 4:26am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/155 "2023-10-29T04:26:36Z")
> [@Bryanm](#): > > We really appreciate the lively discussion [the pricing announcement yesterday](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124) has engendered. We’re especially appreciative of the [replies](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/8) that [understand](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/9) what we’re [trying](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/45) to achieve in the long term, The fact you saw fit to commend someone who said they would continue to run their nodes even if they were completely unpaid is a very good indicator of the real situation here. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [October 29, 2023, 5:07am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/156 "2023-10-29T05:07:59Z")
> [@Pentium100](#): > > I remember that for a long time the recommended way to run a node was to use a rapberry pi with a single hard drive for one node. it was profitable, perhaps today is not, I didn’t check for a long time. But my pi3 recovered x6 of spent money for the 4 years until it’s stopped to boot (because I procrastinated the SD card replacement, but now I cannot be there to replace it). > [@Pentium100](#): > > because people would already be using or not using RAID when they set up their nodes and not redo their servers just to fit the needs of Storj, right? of course, if you have RAID already you can use it. We just warned people to do not build RAID only for Storj, it’s not needed and have an additional costs. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [October 29, 2023, 5:11am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/157 "2023-10-29T05:11:02Z")
> [@mattventura](#): > > that’s slow enough that you could use a tape drive! the usage of BTRFS is enough to have such a long time to respond on the write request, see > [@Fatal Error on my Node](https://forum.storj.io/t/fatal-error-on-my-node/22052/469): > > Thanks for the troubleshooting help. That doesn’t really explain the “used space” calculation being reset every time does it? i know the upload/download errors are a symptom of other things. its really hard to watch the logs when its crashing, cuz they autoclose (by unraid design now…makes sense why, just annoying)…i have to figure out how to stop that nonsense. I have added the extra 30s to the write and read timeout (I added them. Those lines wasn’t there at all…just the verify read/write … ---
**Author:** ![Pentium100](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pentium100/32/6082_2.png) [@Pentium100](https://forum.storj.io/u/Pentium100)\ **Post date:** [October 29, 2023, 5:15am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/158 "2023-10-29T05:15:31Z")
> [@arrogantrabbit](#): > > You should not be backing up node. It’s silly. redundancy is already built into the network. No it’s not. If something happens to part of the data, I cannot recover it and have to lose the remaining data, resulting in lots of free space and $0/month. he node may grow back to the same size it was, but it would take multiple years. Compare this with mining - I only lose the income during the time my miner is offline or is returning invalid data. As long as the hardware works, when I fix whatever problem caused it to misbehave, I resume earning at the same rate as before almost immediately. > [@arrogantrabbit](#): > > Also – why are you messing with your production server?! Do risky stuff in the VM in the test environment. Because sometimes I have to do it - say, upgrading the OS. Normally, I supposed I should transfer everything from this server to another, then upgrade this server and transfer everything back. Also, sometimes stuff happens, that’s why people use backups. ---
**Author:** ![mattventura](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mattventura/32/7831_2.png) [@mattventura](https://forum.storj.io/u/mattventura)\ **Post date:** [October 29, 2023, 5:16am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/159 "2023-10-29T05:16:23Z")
> [@Alexey](#): > > long time to respond on the write request But that assumes that you’re configuring it as a write-through setup, which is pointless. Using a write-back setup instead means you’d still consistently win ingress races because you don’t have to wait for any underlying storage device, and the worst that would happen is you lose a few pieces if you have an unclean shutdown. ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [October 29, 2023, 6:09am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/160 "2023-10-29T06:09:46Z")
> [@Pentium100](#): > > If something happens to part of the data, I cannot recover it and have to lose the remaining data, resulting in lots of free space and $0/month. he node may grow back to the same size it was, but it would take multiple years. If something happens to part of the data – it’s’ not a problem at all. Network will recover, your node will not suffer either. You can lose few pieces here and there. I don’t see how is it possible though if you have a properly setup array, scrub periodically, and don’t mess with the data manually otherwise. If you have a catastrophic failure and lose the whole pool – as a result of I don’t know, a lightning strike – well, multiple the alleged opportunity cost by the probability of this happening and you’ll realize this is not worth worrying about. > [@Pentium100](#): > > Compare this with mining This is an entirely different usecase in every respect. > [@Pentium100](#): > > say, upgrading the OS You never _have to_ upgrade the OS, unless you have vetted that OS elsewhere already. Also, data and OS shall not be entangled in any way. So I don’t see how upgrading OS can mess up your pool either. > [@Pentium100](#): > > Also, sometimes stuff happens, that’s why people use backups. People use backups to protect important data, losing which carries significant cost. Losing storagenode data cost is insignificant, and multiple by probability of loss – negligible. ---
**Author:** ![penfold](https://storj.bcdn.literatehosting.com/letter_avatar/penfold/32/6_22734026db12803ebb3e059622ac3534.png) [@penfold](https://forum.storj.io/u/penfold)\ **Post date:** [October 29, 2023, 6:43am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/161 "2023-10-29T06:43:58Z")
> [@arrogantrabbit](#): > > People use backups to protect important data, losing which carries significant cost. Losing storagenode data cost is insignificant, and multiple by probability of loss – negligible. That is not the only reason people run backups. I use my backups to shuffle around my systems as I try to tweak things. I run a cluster but not all storage is shared as I tend to upgrade storage in one system at a time thus I tend to move things around a bit and the easiest way to do that is using my backups as it means I can prove things are working before destroying the original data. I use that _a lot_ ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [October 29, 2023, 7:54am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/163 "2023-10-29T07:54:11Z")
> [@arrogantrabbit](#): > > If something happens to part of the data – it’s’ not a problem at all. Network will recover, your node will not suffer either. You repeatedly saying this, I do not get it. 5% of data loss is enough to disqualify your node instantly. Why do you think it’s not a problem? ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [October 29, 2023, 8:14am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/165 "2023-10-29T08:14:05Z")
The backup is useless, as soon as you restore it and bring your node online it will be disqualified for lost data since backup. So you need a very frequent backups, or snapshots or do not bring online after the backup is made. ---
**Author:** ![Pentium100](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pentium100/32/6082_2.png) [@Pentium100](https://forum.storj.io/u/Pentium100)\ **Post date:** [October 29, 2023, 8:58am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/167 "2023-10-29T08:58:52Z")
> [@IsThisOn](#): > > That is why it makes no sense to me, that some people here have “sync forced” instead of “async” on datasets. Sync forced is good, assuming the databases are on another filesystem. Data loss adds up, this can especially screw relatively new nodes. ---
**Author:** ![ACarneiro](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/acarneiro/32/1129_2.png) [@ACarneiro](https://forum.storj.io/u/ACarneiro)\ **Post date:** [October 29, 2023, 11:58am UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/168 "2023-10-29T11:58:06Z")
> [@penfold](#): > > The fact you saw fit to commend someone who said they would continue to run their nodes even if they were completely unpaid is a very good indicator of the real situation here. Please do elaborate on what exactly it is that you’re trying to say. ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [October 29, 2023, 3:57pm UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/170 "2023-10-29T15:57:41Z")
I’m talking about few files here and there, lost due to say power loss, or a couple of files rotted. _Few files_. _Not few percent_ of data stored! 5% is massive! 5% of 1TB is 50GB!! If someone loses 5GB of data — come on, that storage is dead long time ago. 5% is too much; if this is how much node is allowed to lose and still remain on the network — this need to be drastically reduced. I could understand 0.05% maybe, but even this is crazy. > [@IsThisOn](#): > > If you reach over 5% something is fundamentally wrong with your node. Yes, this precisely! (I should have read all replies before typing this comment :)) ---
**Author:** ![s-t-o-r-j-user](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/s-t-o-r-j-user/32/7816_2.png) [@s-t-o-r-j-user](https://forum.storj.io/u/s-t-o-r-j-user)\ **Post date:** [October 29, 2023, 4:25pm UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/171 "2023-10-29T16:25:41Z")
> [@Knowledge](#): > > I don’t think anyone is asking for you to give Storj anything for free. I realize there is some philosophy debates going on here about people’s time and costs associated with running a node, but in the end Storj is paying out tokens to node operators and node operators are earning for their node’s usage. Whether or not the financials work in your situation is a case by case basis. With 22k nodes, it seems to be effectively working for a lot of operators. I guess you maybe tried to refer to transcendental idealism by Immanuel Kant and in general to The Age of Enlightenment, not sure if successfully, as I have to admit that the nature of things you are outlining here is more like a fatal doctrine of Arthur Koestler, anyway, not here to discuss philosophy. Just wanted to kindly ask if you may provide me your `zksync address` as I am operating 12 nodes and would be very happy to send you my upcoming October’s Storj earnings so you could go and buy yourself some … `ice creams`. And if you still feeling your army sharpness please look at this from a point of view that you as the company asked for a credit line in a form of cpu, bandwitch and storage space and the credit line was and still is being provided to you. Of course there is a symmetrical relation particularly associated with Storj development efforts so no need to feel offended during your `ice creams` time. I really do hope that you got the message as it is the second decrease in Storj pricing recently and what is more important it is the second time that IMO especially your posts seem to jeopardize the efforts of Storj team … or … maybe I am wrong … and your opinions are reflecting the perspective of your whole company. If you re-read your posts I am sure that you realize that I tried to be very gentle with this post. ---
**Author:** ![s-t-o-r-j-user](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/s-t-o-r-j-user/32/7816_2.png) [@s-t-o-r-j-user](https://forum.storj.io/u/s-t-o-r-j-user)\ **Post date:** [October 29, 2023, 4:29pm UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/172 "2023-10-29T16:29:27Z")
> [@Bryanm](#): > > But if we analyze our costs just for storing data (not including bandwidth) if a customer uploads 1TB of data to our network, we don’t only store 1TB. Because there is a risk some nodes could leave or fail, we actually store closer to 2.7 TB (80/29 = 2.758…). What this means is that for each TB of data we store, we pay node operators $1.50 x 2.7 = $4.05. Our current list price per TB is $4 so we are currently paying SNOs over 100% of our revenue for data stored. I have to admit that I am reluctant to comment on your numbers as I do not have access to your data, however, in this case, I just started to wonder if your calculations are taking into account held amount that is being lost by storage node operators, I guess, there must be some percentage of node operators that are providing you service and later due to various reasons are just closing the nodes. > [@Bryanm](#): > > There was a lot of analysis and work that went into determining the right balance on this incentive. I understand your hard work, however, what is the outcome of this analysis if I may ask, are you sure that the outcome is not the chocked network and an incentive for a new open source cutting edge filesystem called SPSIMOFS (Storj Pricing Strategy Inspired Metadata Only File System). > [@Bryanm](#): > > With the revenue we receive from customers, we also need to cover all of our other operating and engineering expenses to run the company and improve the product. This is absolutly understandable and I hope you will have a chance to look at the other side of the equation as well. > [@Bryanm](#): > > Other projects that are similar to Storj in structure but with much larger networks, i.e. [Filecoin](https://filfox.info/en) and [Chia](https://chiacalculator.com/), are currently paying lower rates for data stored with zero remuneration for egress. > > […] > > Those other projects have significantly higher requirements for more expensive to operate hardware than is required for a storage node in our network. I hope you are aware of the fact that the amount of equipment battered by such projects based on a perfect competition model as Chia is growing rapidly on various auction sites around the World due to various reasons, sometimes very obvious reasons. > [@Bryanm](#): > > In light of that, we don’t believe that the rates that will take effect in December are unreasonable in this market. What is the long term path for storage node operators that you are drawing here with your new strategy if I may ask? What are the key competencies that you are trying to build for your company with this new strategy? How does this new strategy relate to your key success factors and to your competitive advantage long term if I may ask? ---
**Author:** ![peter\_linder](https://storj.bcdn.literatehosting.com/letter_avatar/peter_linder/32/6_22734026db12803ebb3e059622ac3534.png) [@peter\_linder](https://forum.storj.io/u/peter_linder)\ **Post date:** [October 29, 2023, 4:39pm UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/173 "2023-10-29T16:39:01Z")
> [@Bryanm](#): > > Because there is a risk some nodes could leave or fail, we actually store closer to 2.7 TB (80/29 = 2.758…). But this is not true, the effective expansion rate is lower. According to [Grafana](https://storjstats.info/d/storj/storj-network-statistics?orgId=1) the median number of pieces stored is usually around 65 or so. Little higher right now, for some reason. Now I’m assuming the mean is close to the median, the expansion rate is around 65/29=2,2 or so. With a little tuning it should be possible to get this down to around 2 without risk to customer data, although I have to admit I haven’t done this calculation. ---
**Author:** ![Pentium100](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pentium100/32/6082_2.png) [@Pentium100](https://forum.storj.io/u/Pentium100)\ **Post date:** [October 29, 2023, 5:02pm UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/175 "2023-10-29T17:02:01Z")
> [@IsThisOn](#): > > Database should of course not be on asnyc. Not forced async, no, but default. As I understand, the database is wtitten to frequently, but commits/flushes are not as frequent. Remounting the filesystem as forced sync results in a lot of writes primarily from the db. I have not tried this in a while though, so maybe things changed. Maybe the node writes files in a less efficient manner (small buffers etc). > [@IsThisOn](#): > > If my system would have 0s boot time, I could have 864 daily unexpected shutdowns. No, 864 shutdowns in total. Data loss adds up. If you lose, say, 1GB, the 1GB loss will stay with the node forever (the satellite does not remove it from the database once the node fails the audit - it can request the same piece again in the future). Of course, 864 unexpected shutdowns is still a lot, but why make a problem worse. Sure, if my node got so much ingress that it could not keep up, I may be temped to do some kind of optimization like this (though it would probably be replacing the SATA SLOG with a NVMe one, since that would mean the node was expanding rapidly and it would probably pay for it). Not with ~4mbps of ingress. > [@arrogantrabbit](#): > > If someone loses 5GB of data — come on, that storage is dead long time ago. 5% is too much Depends on how it happens. If using a single drive, a bad sector in the wrong place (filesystem metadata) can make multiple files disappear. IIRC on NTFS with 64K cluster size a single bad sector in the MFT makes 64 files disappear. ---
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [October 29, 2023, 5:04pm UTC](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124/176 "2023-10-29T17:04:11Z")
> [@Pentium100](#): > > NTFS with 64K cluster size a single bad sector in the MFT makes 64 files disappear. Come on, who has a node with this clustersize? [Previous page](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124.md?page=7) [Next page](https://forum.storj.io/t/announcement-changes-to-node-payout-rates-as-of-december-1st-2023-open-for-comment/24124.md?page=9)