RigoBlock / contracts

[DEPRECATED] directory of our contracts
Apache License 2.0
1 stars 0 forks source link

pop algorithm overflow attack vector #13

Closed gabririgo closed 6 years ago

gabririgo commented 6 years ago

using the value of a fund in relation to the network value requires computing the value of the network, which could overflow with a big enough number of funds.

furthermore, the estimate of the network value could return an error in the case a price is set to 0 (not possible in standard fund however) or in case a fund is unregistered. In this latter case, the estimate call would return an error.

Better solution: apply the same method as applied in the casper block reward (which itself is similar to the standard pow miners' block reward): a block reward is attributed to each trader at each epoch (an epoch is a predefined interval between a certain numbers of blocks).

this allows further to differentiate for different factories and attribute diffferent block rewards to different factories (i.e. vaults vs dragos vs ethstakers).

The account calling the claimReward could be awarded some minimum amount of eth, in order to pay for gas costs of the transaction (double check whether viable as price of eth is not stable) and anybody could call the function. Hence we could make the call on behalf of manager as well

gabririgo commented 6 years ago

proof of performance now rewards both assets and performance with adjustable parameters, it is not subject to the same attack and inflation increases as funds in the network increase, so we can adjust the total inflation by lowering the epochReward. We now have an epochReward which is a uint of 10^18 zeros, so it can go much lower in case there is a huge increase in demand. Cool thing about the new algorithm is that tokens increase when demand increases, the Rigo token total supply is responsive to demand