I understand that you feel missed the opportunity with higher price. But it’s totally wrong. We are not playing with market. All charges and rewards accounted in USD. They converted to/from STORJ only on date of transaction. This minimize the risk of tokens volatile.
This decision just make worse the situation for you:
You can easily solve it - specify only one address and you likely may reach a threshold.
The other option is L2. With it you will receive STORJ without minimum threshold and can withdraw them to L1 when you want and will pay fee for withdrawal.
I get what you are saying, but for anyone whose cost currency is not USD, you are playing the market (when paying late).
True, you are not playing the “Storj / USD” market, but you are effectively playing the “USD / SNO’S_cost_currency” market on the SNO’s behalf.
What I am saying is that it would be more fair if I could chose which market is played on my behalf – as I just explained, one of the markets is always played, as my cost currency is not USD.
I understand that. My feedback was about the past two months, and as well towards possible future situations, when payments are delayed again, for whatever reasons (I suppose a delay can happen for some now-unforeseen reason even with L2 zkSync or any future solution).
Let’s end this thread as I think everything relevant was already said.
Is it?
Well maybe it is, but most SNOs having multiple nodes do that.
Besides, it’s even the recommended way (according to Storjling people) to add more storage disks, so I doubt this would be a problem.
Ingress is shared anyway between nodes behind the same IP (in fact, behind the same /24 subnet), so all these nodes are kinda handled by satellites as a single node.
I don’t want to speak in place of official StorjLabs members, but I’m pretty sure it’s fine to run multiple nodes behind one IP.
You’re conflating two separate things. You will always have the fiat exchange rate apply simply because you are dealing with a foreign entity. This is completely separate from the crypto currency market risks.
And you can’t seriously be suggesting that the risks are even close to the same… Let’s be real please.
But furthermore, the suggestion you are making fixes something that will already be fixed by zkSync. Except zkSync also fixes the delay that caused your request to begin with.
So, the simple answer is your suggestion would cost considerable developer time which should be spent on zkSync because it’s a more complete solution.
Yes last I checked it was still in the ToS. But Storj Labs has several times explicitly said this was now allowed. The ToS should have been updated for that a long time ago, but it seems they never got around to it.
To be honest, with the current payout threshold and zkSync options I would suggest also reconsidering the limitation of a single payout address. As it’s now just up to the SNO to shoot themselves in the foot or not.
It didn’t used to be, that’s why this was in the ToS to begin with. But when the IP filter was implemented this should have been removed from ToS.
5. Restrictions. You will operate the Storage Node in strict accordance with the terms of this Agreement and in no other manner. Without limiting the generality of the foregoing, you will not:
Operate more than one (1) Storage Node using different Payment Addresses for each Storage Node;
Operate more than one (1) Storage Node behind the same IP address;
So, first one is ok and second one is wrong because it has been said in the forum you can run multiple nodes behind one IP?
On the forum, during the town hall on the blogs. They’ve said it pretty much everywhere. So yes, I’m certain running multiple nodes on one IP is now fine. Do it myself actually. But I’m still not a fan of it still saying this in ToS. Muddies the waters.
I think over time they learned that if one of your nodes fills up there’s no other way to expand your node so this is why they allow you to run more then one node behind the same IP.
They never added the ablity to just add another hard drive to expand your first node and they don’t recommend using raid. Rather then buying a new hard drive putting your node offline to transfer all the files to a new hard drive taking a chance it failing and DQing your node.
Not knocking deathlessdd (as I feel they are still a way more experienced SNO than me) but drives can be easily migrated without risking DQ. At least on the Linux platform, Windows looks to have extra steps I haven’t tried. I migrated my first RPi node to a larger drive following the directions on this page. The directions are pretty solid. Don’t think I even missed an online check.
Then we meet the same problem on Bitcoin network and migrated to the Ethereum
Now we have exactly the same problem again.
Blockchain networks are not scalable enough to be cheap as in the beginning.
Unfortunately the wire transfers are not available for everyone unlike tokens. In some countries receiving foreign currency even illegal.
How many countries would be excluded?
If that’s the main reason to avoid fiat transfers then I would be curious to know how much risk you’re mitigating by creating this unholy mess of crypto payouts.
Even one would be enough. The wire transfers are acceptable for US and some EU countries only.
All other will have problems. Fiat have many restrictions in our world. In most of countries which have an own currency the foreign currency can be received only by legal entity. There are also difficulties with taxation, if you receive not native currency. With tokens those problems much simpler - you can pay at least income tax without creating a legal entity.
This discussion is going nowhere - we do not have plans to pay in fiat anyway.