iamtrask / DEPRECATED

DEPRECATED - do not use!!!
Apache License 2.0
349 stars 48 forks source link

Mining Rewards #1

Closed ghost closed 6 years ago

ghost commented 6 years ago

Under incentives, it's stated that "It’s also advantageous for a mine to begin training a dataset as soon as possible since the potential change gradient is higher at the beginning of training.". Under these conditions, a rational miner would be incentivized to exclusively contribute to new campaigns. Is there anything stopping a miner from simply mining the first % of a project and then jumping ship as soon as it detects that a new project is available, thus ensuring maximal reward for all mining contributed while never actually doing the hard work that gets a model trained to the point that it's useful?

iamtrask commented 6 years ago

Great question. There's nothing other than computational bottleneck to prevent the miner from working on both simultaneously, at which point the $$ reward just needs to be high enough to justify the compute.

Also, the advantage early on is primarily based on the fact that the loss in a network moves the most early on (we're tieing $$ to validation error). Thus, even though it happens fastest in the beginning, each miner has to wait a while between "digs" because sending gradients based on the same data to the same model back to back will just cause it to overfit (which eventually causes the validation set to diverge)

So, it's actually a good thing for them to mine for a while, then mine something else, then come back and mine some more (and the financial incentives tied to validation score automatically make it work this way)

anoff commented 6 years ago

Oh I never thought about a Mine training a net multiple times. Should there be a limit sonar -side for the percentage an individual mine can contribute to a network? I imagine that overfitting will only become obvious when it is too late

iamtrask commented 6 years ago

So on one hand, overfitting prevention will be enforced by the fact that overfitting causes the validation score to go down. However, I think it'd be wise to include some hard metrics that prevent a miner from mining a network too often (like a minimum number of other miners that have to mine before a given mine is allowed to repeat)

anoff commented 6 years ago

https://github.com/OpenMined/Sonar/issues/2 this is planned already for hydrogen💧 right. Does this close the issue? @kirtanechiron should we add trasks response to the FAQ ?

iamtrask commented 6 years ago

great point. closing!