Bye bye for now

Then please show your work, because economists don’t just throw out claims without supporting evidence.

I’m still open to more detailed feedback on the earnings estimator topic, but so far your experience doesn’t seem to represent what most people see.

So, I provide a link that has stats on literally every day and your response is a single block… Everything I said was factually true. Please just actually visit the link, zoom in on the days since the London fork and look at actual daily stats.

1 Like

I can’t provide feedback on a node that no longer exists. But my earnings were at no time larger than $17 total inc this month’s pay for 1.5TB with no downtime on the node i removed.

My secondary node has a total amount owing inc this months pay for $3.00 approximately on nearly 500GB.
Secondary node’s data is going up since the primary shut down.
Secondary node will revert to 25% withheld next month at 7 months. Secondary node did have 3 days shutdown last month but that is all. I’ve had no home internet outages in the last month and I am on a fixed ip. We have had no power outages either.

I’ll investigate what I can do for you here.

Nothing you have said or is in the link contradicts me either. Indeed the financial commentators seem to indicate agreement with me.

Love how you completely ignored the commentary on Storj’s payment methods. I think we can safely assume from that you aren’t aware of any Exchange’s yet for L2 either. So I fail completely to see how you can claim Storj’s payment model works. I still believe we will see yet further pressure on L1 gas fees.

I’ll say in advance I am not a Keynesian and sit more in the Austrian camp side of things.
Big fan of Milton Friedman’s work. Can watch his talks for hours at a time.

The quantity theory of money proposes that the exchange value of money is determined like any other good, with supply and demand. Yes, I am equating ETH to a medium of Exchange here.

​(M)(V)=(P)(T)

Where:
M=Money Supply V=Velocity of circulation P=Average Price Level T=Volume of transactions of goods and services​

One problem in that equation is calculating V or the money velocity as that is based on a calculation of using GDP and GDP does not apply in this case.

However, we can see that $17,918,463,350.85 or 11.17% traded in the last 24 hours. So it means a significant % of the volume is trading and therefore velocity will be high.

How high exactly - not sure. But it is going to be a lot more than ~1 which is the sort of space normal fiat currencies occupy.

Then the next issue is to calculate T. This is also complicated since it uses Indicies and purchases with crypto coins don’t happen isolation from fiat currencies… You need a measure to equate things of different values. (is 1 expensive car sold equivalent to 2 cheap cars or 200 bikes as a basic example)
This is my reference I am currently working through:

Essentially what I’ll need to do is use work out the value of trades by traditional methods and then subtract that from the total trades. Then work out the percentage of the market ETH occupies.

Right, I forgot that you had 2 nodes. And yeah, it’s hard to get the stats from a shut down node of course. Thanks for this though, it does help, but it’s not enough information to get an idea about why you saw less ingress in total. (Earnings estimator would predict the total you get per IP, not per node, in this situation) It gets a little complicated when there are 2 vetting periods involved, but I still wouldn’t expect total performance to deviate so much from the predictions. I have a feeling that it might be because I calculate deletes as a percentage of total storage, but don’t account for most deletes hitting recently uploaded data. So I underestimate the pressure of deletes on younger nodes. I’ll keep an eye out for that. Thanks!

Well when you flatout deny something I said, only one of us can be right.

And I provided a link that shows you that in fact ALL days more ETH is created than burned. There is just a small amount of days on which that is not the case if you don’t count staking rewards (which I would agree should probably not be counted as for now those are locked on the beacon chain). You also at the least heavily suggested that the total ethereum issuance went negative since the london fork.

Here

and here

That didn’t sound like you were talking about individual blocks, but rather a consistent trend.

I didn’t respond because you didn’t really bring up anything new. I had already explained that it works and payouts are going out. It didn’t seem useful to continue the “yes it does”, “no it doesn’t” back and forth.

No need to assume, I’m not aware of any and if I do come across one, I’ll certainly post it here on the forum. We’ve seen one of the founders of the numio app on the forum promise that trading on zkSync will be implemented in their app soon though. So might want to keep an eye on that.

Well, that’s kind of the problem with absolute statements like “it doesn’t work”. My response would simply be: “I’m getting paid almost every month… seems to work just fine”. It’s not a black or white thing. Saying it doesn’t work suggests nobody is getting paid ever. We both agree there are problems with the system as it is. So it’s somewhere in between. I’d rather discuss specific issues than make broad statements about it working or not.

I see what you’re getting at here, but I’m pretty sure this assumes a single currency market. You noticed already that you can’t just apply GDP here, which is a result of this difference. That was kind of my point. This isn’t just basic economics, it’s a super volatile market with many variables impacting value.
While it’s true that reduction in supply (or even a slower increase in supply as it is in this case) puts pressure on the price. This impact isn’t large. We can actually isolate that relatively easily. Before the london hard fork, we saw in a year time a roughly 5% increase in total supply of ETH. So all other things staying equal, that would cause 5% inflation. Extrapolating the supply increase since the london hard fork to a year, the new inflation would be around 2.3%. So at most this change would have an impact of 2.7% on the value over a years time. Since the transaction costs multiplied many times over, this can’t possibly explain that. In fact 2.7% over a year is basically negligible in volatile crypto markets.

Btw, will you be joining the Node Operator Fireside Discussion ? Would be great to have you there so you can address some of your concerns with Storj directly!
Edit: I see you already added questions in that topic, awesome!

1 Like

For one guy leaving there’s another one joining. Just started to get to know storj and setup my node today. Shutting down all my sia nodes and use it for storj (about 100tb on a 10gbit wan).

3 Likes

Welcome @M4nu,

You should take a look at the earnings estimator as adding 100TB in one go, on one /24 subnet won’t be the best for you.

4 Likes

Hold off on that for now and just make enough space available for the first few TB. As @Stob mentioned, it will take a long time to fill up. I currently still run Chia on space not used by Storj yet. And it can easily run in parallel on the same machine.

1 Like

So, to clarify, there can still be inflationary pressure even if the quantity issued increases if the change in demand is greater than the quantity issued. If I suggested the total ethereum issuance went negative since the London fork, that was not my intention at all and I withdraw it - my understanding was you were suggesting that the issuance of ether was never lass than the amount burnt and that clearly was not the case for at least one particular moment of time.

I really was only talking about a particular moment of time. Not even a particular block.
They did cross the threshold - and then promptly went back under it.

I’ve signed up with them and signed the secondary node up to it for now since I have given up on all hope of L1. It is interesting, deleting the primary node actually made it easier since I basically gave up and no longer really care since the income is completely insignificant and will remain so for another 12 months at least now. If it runs, it runs. If it dies, it dies. Meh. I’ve stopped looking at the dashboards every day that is for sure.

Well, most countries don’t use more than 1 fiat currency. But that wasn’t the primary problem in my head. The issue is more that cryptocurrency is borderless. So calculating totals needs to be global.

It still supply and demand at its core. Just a hell of a lot of factors impacting both.
If it is “basic economics”, why does the world lurch into crisis after crisis every 20 years? lol

That is inflation in the quantity of tokens - not their buying power. An increase in the money supply so to speak. An increase of 5%of the quantity of tokens with all other things staying equal should result in deflation of their buying power. They should be able to buy less - since there are more of them available. So it would be inflationary prices of items bought or traded with ETH. Including gas fees. i.e. you need more ETH for the same transaction.

I do not exclude other additional factors at play here - including the Chinese crackdown on miners and Exchanges. But, it remains that burning ETH should have been seen as a potential pressure on gas fees - even though it is undoubtedly not the only one.

The fireside discussion was very underwhelming for me. i understand they have limited time but I’m not really sure it was worthwhile.

same here, other then F…C…n

Got it. No, what I said was that there was never a full day for which that was the case (at least not if you take staking rewards into account).

If you still have pending payouts on that first node, you should try and switch that too if you still have the identity. You just have to start a new node with the same identity once and let it check in with the satellites. If there was a decent amount still pending that might be worth it.

Yeah, they could have made a bit more time for it. They said they went through all the questions, but there were way more than what they addressed. To be fair, I think they got a little overwhelmed by all the last minute questions that were added. Hopefully they will host more of these. There was some interesting info in there.

As for impact of the London fork. I think most of the price impact was more about speculation than the whole inflation/deflation debate. That speculation led to much more trading, which boosted the costs.

I’ve been running daily backups on my dev server since 2012 and it is setup to retain the last 30 days and then 12 monthly backups. HashBackup does pack user files into large 1GB files. As user files are modified and re-saved, it makes older versions of that file obsolete, so “holes” get punched in the large archive files. When the ratio of holes to data gets too high, usually 50%, these old backup files have to be downloaded, repacked, and uploaded again. The download doesn’t occur if there is a local copy of the backup. And even if there isn’t a local copy, HB only downloads the active parts of the large archive file using ranged gets, so even if a download is needed, it’s usually not for the whole file.

Here’s a distribution by year of the backup archive files on my dev server:

[jim@bs hbbackup]$ uniq -c out
 117 2021
  62 2020
 228 2019
  43 2018
  66 2017
  70 2016
   8 2015
   2 2014
   8 2013
  28 2012

The 28 files (these are large 1GB blobs) that haven’t changed since 2012 are likely OS files like /Applications, /usr, etc. that were saved in the initial backup. The pattern is disrupted in 2020 because the virus made me lazy and I didn’t do much development.

As backup archive files age, they are more aggressively deleted, with the remaining active data packed into new, smaller files. So at least the way HB works, the backup doesn’t accumulate more and more older files. I think the only way you would see that pattern is if all backup versions were kept, ie, your retention policy was to never delete anything from the backup.

1 Like

That is great. Are you now claiming that you are the only customer in the network? I have to reapeat my question. If we assume that all customers would behave like you why don’t I see that behavior on my storage node? I can observe a steady increase in download traffic even on nodes that are full since months.

Well, I think we can look at node stats to make some rough determinations. I only have 3 nodes, so I’m a little hesitant to draw definitive conclusions on that relatively small sample set. But, here it goes.

Egress percentages this month so far compared to amount of data stored.
Largest node that has always had free space: about 5.8%
Smaller node that has been full for about a year: 3.8%
Another small node full for about a year: 3.1%

This does suggest that recently uploaded data is downloaded more frequently. That also kind of makes sense for most use cases I can think of. Backup probably doesn’t trigger much download at all, but if it does, you’re more likely to want last weeks version of data than a snapshot from years ago. Videos get more views right after being uploaded. Security footage is most likely to be watched shortly after being created. Software distributions see a peak shortly after a new version has been released.

Something similar goes for deletes. If a file has been around for a few years, it’s much more likely to stick around another year. This is something I’ve observed as well on my full node. One of them is at the limit, while for the other I’ve lowered the limit far below the amount stored. The one at the limit will sometimes see some ingress as a result of deletes. After being full for the first time, that was usually quite large amounts. high 10’s of GB’s. But as the months passed that amount got a lot lower on average. Eventually it was just a few GB ingress per month and it recent months it has become closer to a couple hundred MB’s of ingress. (I’m using ingress as a stand in for deletes here as we don’t have good node stats on deletes, this should work just fine on full nodes though)

So yeah, it does seem that long storage data piles up a bit on full nodes and maybe sees a little less ingress. But there are tons of caveats. I have only 2 full nodes to test with and they collected data during a similar timeframe. It could very well be that the most common use cases at the time were different than they are now. So you can’t use my experience exactly to determine what your node will look like in the future. If you happened to fill up your node during a time when lots of frequently accessed data was pushed into the network, you may even see the exact opposite effect. So take any conclusions on these stats with a grain of salt. And if you suffer from FOMO, just make sure your node always has free space. :slight_smile:

1 Like

I never got a payout on the node ever so yeah, there is some pending. $13 USD if I recall.
The current month was only going to pay another $3.00.
I switched it to the Numio wallet 24 hours before deleting it.

1 Like

I don’t know if you noticed but there was a key statistic mentioned - average node life is 9 months.
What does that say about node churn and L1 payments?

I’d have to go back to the video, but I believe they said the network was built around that assumption. I’m not entirely sure that was actually a real statistic. But even if it is, that doesn’t tell us a lot yet. There are probably lots of nodes that check in, but never resolve port forwarding issues. Others who never get out of vetting phase and many more. Those do barely any damage to the network, if any at all, but would drag down that average a lot.

We would need a bit more info, which is why it’s one of the questions I asked. But the response was basically: “Don’t worry about it, we don’t think it’s a problem”. And I’m sure it isn’t a problem for the network. But it may point to SNOs not being happy.

1 Like

That is my assessment as well.

My oldest node is 17 months now. 3.25 TB stored. I have reduced allocation to 0 before the recent increas in customer uploads. So without the latest develpment my download traffic is 5 % customer downloads and 5% repair downloads so 10% in total. I see that behavior on most of my nodes.

It is not possible to predict the customer behavior. I wanted to track the number of downloads per pieceID. My idea was to identify customers that upload mostly backup data and never download it. It would be allowed to reject the upload. However I ended up not doing it because it would reduce my payout. Let’s say from 100 backup customers 1 needs to download the full backup. That would still be 1% download traffic. My bottleneck is my internet connection. I want to max out my connection with customer downloads. Hard drives are cheap. So what I need to do is fill my hard drive with as many backups as possible and take the money if one of them needs to restore the backup. A customer might upload a video file and share it. First few month barly no hits and suddenly it get postet several times in a short time generating a hugh amount of download traffic. I don’t think the assumption is correct that old data has to fall behind in download traffic. At least not on my nodes.

If you want a full understanding of the how frequently files have been accessed on a linux system you can always run agedu.

As my node is a Pi with a single spinning disk agedu took 36 hours to run against my 6TB of storage as it creates a data file and then uses this to create a reporting database. All the resulting IO on the same drives as STORJ is running against is painful.

Sadly the resulting heat map shown in the web output is not that useful to share, but for my system, about 50% of the files had not been touched for over 6 months.

1 Like

Vadim, I had hoped to emulate your setup over the longer term but I no longer think that is possible with current data levels. Maybe that will change as adoption grows.

  1. Every isp connection is a cost that needs to be paid for.
    It means a SNO would be in the hole for a significant period of time before even breaking even.
  2. If a SNO has only a single ISP then it means 9-10 months before even one payment - as the L2 system is still useless for now in terms of using it to offset costs.
  3. Surge payments that existed during the early part of the network life have gone the way of the dodo.

I just don’t think at current usage levels anyone can replicate your setup without incurring significant additional costs. Maybe if one has a large extended family where you can locate nodes on different isp’s. :slight_smile:

1 Like