So are you saying that since we already have potential issues with using the ethereum platform in general, which may have security concerns (I agree with you on this and let the record show I was not happy to see the project migrate from bitcoin to eth 3 years ago for this exact reason) - we might as well introduce even more security concerns now? I don’t think that is a valid argument.
No…
I’m simply putting forward the reality that trust has very little meaning when discussing vast and complex network connections and interactions.
The Storj network does a decent job on handling end-to-end authentication. And this is the most important component. The locally generated and controlled CA and node certificates allow for authentication to have a high level of assurance for traffic generation/acceptance.
The payments side, however, is not quite so well protected. It would be better if the payment address could be accompanied by a signed nonce coming from the Storj satellites… A payment smart contract could be written such that outgoing payments from a satellite to an SNO are reverted if the address doesn’t return the signed nonce before final payment processing.
Alas… I’m sure the dev time is limited, and we will all need to trust that the Ethereum network delivers all payments properly.
Thanks for the supportive message… I’m not the OP of this thread… hopefully the OP agrees with my posts and I’m not just rambling, as per usual.
Guess this warrants a request on the idea portal.
Created, vote here
1 Like
Btw much effort has gone into our payouts automation already, including a lot of time spent on the problem of verifying that all payout transactions were correctly sent. We do not just trust the ethereum network on this one (Don’t trust, verify). We went through many iterations to get this right, starting with the V2 payouts, to get to our current implementation, were we are now at a point with our present version that we have not had anyone file a ticket about their payouts where we would have had to make any correction (all turned out to just be a matter of the SNO not knowing where to look for the TX, or not waiting for payouts to complete before filing a ticket). So this is an ongoing effort and more suggestions for improvements I think would always be welcome.
1 Like
I’m certainly not complaining about the payment flow… However, as an SNO, I have nothing on my side of payments transaction that assures me that the payments have been processed correctly and settled fairly. I can use a third party log filtering tool to estimate expected payout, but many times the actual payout is not precisely the same as the expected payout.
Again, I’m not complaining… nor worried… nor indicating that there is/was any problem with the payments or accuracy of the settlement of payments.
However, you’ve posted that much effort has gone into assuring that the payments are correct. But an SNO still doesn’t know… and has no independently verifiable audit trail… instead all SNOs must trust that the payments are accurate… in order to verify, SNOs need to submit a ticket and trust that the support ticket will be treated fairly.
I’m merely saying this is will most likely become common place, assuming the adoption for the protocol hits critical mass. Not to support it right away, more food for thought and to keep an eye out.
Tons have registered domains already. All-in-all the DNS works fine for the internet, which is mostly decentralized. No reason a smart contracts can’t handle ENS. Since the payment system has already been worked on. No reason to change to this right now. They, ENS, do need to work more bugs out before high adoption will take place.
Please add this idea to the ideas portal or upvote an already existing idea requesting this feature. This is how devs would be able to prioritize it for development. Other SNOs have been satisfied with the accuracy provided by the community made earnings estimation scripts so far, so until something is implemented by Storj to substitute this, I suggest SNOs use the scripts for the meantime.
1 Like
this is a different issue, it is about payouts verification, not ENS implementation.
Another registration required for another storj subdomain… sigh… Since I quite obviously don’t like putting my IRL name into the registration form, I guess I’ll put “beast, the” …
Added to the idea portal…
2 Likes
Was reading though this think again before you want to run this site.
2 Likes
Sorry to be blunt, but the article is FUD.
All the screenshots listing transactions are pulled directly from Etherscan… and have nothing whatsoever to do with ENS.
Identifying high value addresses in Etherscan is extremely easy. There’s even a button to nicely graph the holders and/or sort them. And after sorting the holders of any Ethereum asset on Etherscan, one can download the first several thousands addresses in a nicely formatted CSV file. However, ENS does not help in identifying individuals unless those individuals register a personally identifying name…
EDIT:
… And sign a statement on the blockchain identifying themselves.
Anyone can register any ENS domain. No proof of real life identity is needed.
The intention of this thread was to bring awareness of new protocol(s) that are going to make the adoption of crypto much higher and easier to manage.
Now ENS might not be the company that wins this. I would hope native block-chains would support this vs a third party. Completely love the idea of making your wallet address something easy to use vs getting a QR code or copy/paste the address.
It just to prove there already watching and making it easier to find there 0 privacy. And on the site you have to pay for the service so your name will be on it sorry to say. It would be a registered domain which you can search on google and find names.
Anyone running a Storj node presumably has at least one Ethereum address and has been paid in STORJ…
Here are all the transactions made with STORJ.
You can page through all the DEX trades and probably find your own with very little difficulty.
ENS does not make anyone more of a target or more trackable.
ENS does provide an easier to read and use address identifier.
1 Like
