This doesn’t require any additional data. All of it is already there, with the exception of the exchange rate and STORJ amounts. Which would just be 2 additional variables in the pay stubs table. The earnings calculator already shows the calculations based on the nodes own accounting. So that’s why you sometimes see small differences between the earnings calculator and the web dashboard.
But wouldn’t it need another database just for the invoice data and exchange rate data stored in a new database? Also wouldnt the node need to pull data to get exchange rate and store it somewhere so it can compare and verify it.
yeah ease of implementation is by far one of the major factors that should be taken into account, building new stuff always seem so much more simple than it actually is…
so many tests and failures over time because of things one didn’t take into account… making good stuff is near impossible atleast on the first go… takes a few revisions before stuff gets really good, and extensive long term testing…
So the simplest implementation and then give it time to figure out what would actually be the best approach… i generally find that my best work is when i give stuff time to materialize…
good ideas doesn’t come easily and bad ideas one can get stuck with for a lifetime… xD
ofc temporary solutions often become permanent, so it’s best that it’s not some half assed solution either, but that doesn’t mean one has to invest massive amounts of work into making something work…
most often there is a path of least resistance, something which nature and the universe is very fond of utilizing time and again…
i should get paid for this… xD
No, this is exactly the data that is already available in the paystubs table in heldamount.db (yeah, that db name doesn’t make much sense anymore as it contains much more than just held amount).
Satellites already report this data back to nodes and it’s what’s displayed on the web dashboard for previous month payouts after payouts are done. So all that would be needed is add the exchange rate and STORJ amount to that data. The node shouldn’t collect this itself, the satellite needs this information to make the payout, so it should already have it and report it back to the node along with the data already there. What I don’t know is if the satellite stored that information before, so it might not be possible to backfill it for previous months. But it should be fairly easy to include it for future months.
And while we’re at it, why not include a transaction id or link to etherscan.io? Though I guess that’s a little less relevant now that they will all be combined.
1 Like
Oh I see they do have all the data in the tables I haven’t went though the databases myself thanks for showing that to me. Makes alot more sense to me now. It should be possible to send us an invoice of all the info we need or least show it on the dashboard. But if this is the case I think the dashboard will need to be a bit more secure when all this information is on it for the people that have there dashboards public.
sounds like it’s time to move on to the suggestions and ideas…
i like the simplicity of implementation with your suggestion and it from what i understand solves all the issues with ease…
Some sort of accrual rule makes a lot of sense. I’ve started a 1TB test node and the first payment I have received is 0.00647 storj, which has a $ value of basically $0.001. regardless of how high or low the payment fee is its going to be greater than the sum transferred.
1 Like
So if the fees of ETH are getting to high, they have 2 options:
- Creating own cryptocurrency
- Making an token an another Blockchain, perhaps they should look at Burstcoin. Its fast, green and has cheap fees, smart contracts and more
- Using another cryptocurrency that is fast and cheap (and safe)
2 Likes
Aggregate all payments into one per month. If its <5x the transaction fee, wait until next month.
3 Likes
I don’t know if those smart contracts are required. It was my understanding that they created their own token mostly for payment processing. I don’t know if there is so much smart contracting logic in that.
If that’s true any other crypto could be used. Creating own crypto requires many additional assets like blockchain and miners that need to be managed as well and might not be feasible.
But also creating a token on a different cheaper platform should be totally doable.
Those fluctuating transaction prices are an idiocy in cryptos basically preventing them from being used.
Which platform would you suggest ?
Stellar Lumens? Would it be doable?
Don’t get me wrong, I think ETH is the best network but in fact, 1600$ just in transaction fees is outrageous.
Why not 1 payment per eth address independently of satellite and node?
Now that we have payment dashboard working on snos I think NOW it makes sense.
1 Like
If you read it carefully it was paid while using SJCX not Storj token.
I agree.
You’re right, my mistake. Even so, I think now that dashboard is working, would be better 1 payment per eth address for all satellites.
Because honestly, I don’t even see the point of being segregated by satellite…it’s something I really don’t care…all I watch is the total I get regarding the project
You mean this…?
2 Likes
.You do realize that’s quoted from the first post in this thread
4 Likes
We should be able to withdraw the payout when we want.
Or else be able to send the payout (or part thereof) somewhere else when we want.
As for Ethereum: this is what we get by not being independent, you rely on the seigniorage fee of the issuer, and that exists since money has been invented.
The cheapest and easiest route would be to issue tardigrade vouchers that do not expire. And tardigrade credits should be transferrable to any other account for free! Call it STORJ tokens to escape money transmitting license requirements. This will result in an ecosystem (“eco” being economic~ not from ecology).
I am not saying everyone should be switched to tardigrade vouchers~ but at least enable this option for those whom want it.