Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proof of work - better calculation #11

Open
ghost opened this issue Jun 5, 2018 · 11 comments
Open

proof of work - better calculation #11

ghost opened this issue Jun 5, 2018 · 11 comments

Comments

@ghost
Copy link

ghost commented Jun 5, 2018

Use a better proof of work process to make a more meaninful work.

Also the score should use more parameters to be more specific

@0crat
Copy link

0crat commented Jun 5, 2018

@yegor256/z please, pay attention to this issue

@0crat
Copy link

0crat commented Jun 5, 2018

@oltdaniel/z this project will fix the problem faster if you donate a few dollars to it; just click here and pay via Stripe, it's very fast, convenient and appreciated; thanks a lot!

@yegor256
Copy link
Contributor

@oltdaniel I'm not sure I follow. What exactly are you suggesting?

@ghost
Copy link
Author

ghost commented Jun 20, 2018

@yegor256 We talked about to choose a better proof of work algorithm to stop this meaningless iteration of hashes.

@yegor256
Copy link
Contributor

@oltdaniel what would be a better option? I'm open for suggestions.

@ghost
Copy link
Author

ghost commented Jun 24, 2018

@yegor256 The score is currently based on the hashes a node calculated. These hashes are generated by generating a new SHA256 hash that has :strength: leading zeros. This results in an new alias for the score, computing power per node. To make this a more meaningful calculation, we could let the nodes hash the wallets over an over, and set a score based on that, which will lead to the same result (yes, this will require a new formula) and represents the computing power per node as well as the wallet count parameter in one score.

And last but not least, scores can be affected by other parameters too, like uptime, served wallets, and traffic handled by the node.

@yegor256
Copy link
Contributor

@oltdaniel so basically you are suggesting to add more text to the initial "body" of the score?

@yegor256
Copy link
Contributor

@oltdaniel what is the objective of all this? What problem are you trying to solve?

@ghost
Copy link
Author

ghost commented Jul 29, 2018

@yegor256 Hashing the wallets could change the score from computing power per node to importance of the node since it provides a hashing power with wallets. On this way, a high number of wallets and computing power gives a high score which then represents the importance of the node to the overall network.

@yegor256
Copy link
Contributor

@oltdaniel how can we validate the number of wallets a node stores? A node can easily fake that number and claim to contain a million wallets. How can we check that?

@DronMDF
Copy link

DronMDF commented Oct 22, 2018

@oltdaniel @yegor256 I have other idea about this.

Current score does not guarantee that the node gives valid information.
The node does not pay for the information that gives.

The proposal:
Each node mine current content of wallet... <wallet hash> + <nonce> -> <wallet approve value>
For each wallet in database.

  • If client get wallet - node pass approve value to them. Otherwise we do not trust the node.
  • It is necessary to choose the mining parameters so that the entire base is mined from scratch for quite a long time. Maybe a week (15-20 seconds per wallet is ok). This will increase the entry threshold. This is necessary to complicate the attack 51%. Recently there was a story that some currency was attacked by buying AWS for several hours.
  • If you need to pay a tax, you can choose any (randomly) node that confirms the contents of the wallet.
  • Since the node can not immediately confirm all the wallets - You can choose which of them are the most attractive for the site. Pay a tax for an example. Or have to pay. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants