Open theoreticalbts opened 6 years ago
@mvandeberg I would appreciate your input on this issue.
The reason behind the implementation is that while the VESTS/STEEM price may decrease when rewards are claimed, the delay means an author always receives fewer VESTS than would have if vesting happens instantly. Vesting cannot happen instantly because it makes content a dependency of vesting balances, which are needed for the witness schedule. Thus making content required for the minimal module. That is a non-starter for scaling. I think within the context of STEEM, the errors are minimal enough that it is not a problem.
However, SMTs have the possibility of pushing corner cases, it may be warranted to re-evaluate this assumption. It really depends on what you define as stealing. For VESTS holders, a large reward being claimed does make their value decrease. However, only as much as you consider that their value is artificially higher than it should be because the rewards aren't claimed. The same argument can be made for the author that if they don't claim for a significant period of time, they end up with a smaller reward. (Opportunity costs from not vesting)
There are two reasonable behaviors for the Steem Power portion of post rewards: Either the reward for a post is vested when it is rewarded, or the reward for a post is vested when it is claimed.
The code does not implement either of those two reasonable behaviors. Instead, it implements rewarding a post with Steem, plus an option to vest that Steem at the VESTS / STEEM exchange rate at the time of the reward. Claiming rewards exercises the option, which generates profits since the actual exchange rate at the time of the claim is less favorable than the exchange rate at the time of the reward. Profits from the option exercise are funded by corresponding losses from the vesting pool.
Existing implementation
Here is an example of the bug at work:
reward_steem_balance
is 10 Steem, and Alice'sreward_vesting_balance
is 10 VESTS.claim_reward_balance_operation
.How many VESTS / Steem does everyone have after this sequence of events occurs?
10 * 1510 / 1010
, or14.95
Steem.10 * 1510 / 1010
, or1495.05
Steem.Carefully checking the numbers demonstrates that 4.95 Steem worth of value moved from Bob to Alice.
In this example, Alice represents 1% of the vesting pool, and the vesting pool was increased 50% from emissions. The error is approximately equal to the original vesting pool times the product of these two percentages, in this case, 0.5% of 1000 Steem. Fortunately for us, the error is hopefully small:
Vest when rewarded
What happens if post rewards start vesting when they are rewarded?
10 * 1510 / 1010
, or14.95
Steem.10 * 1510 / 1010
, or1495.05
Steem.This is the exact same result as given by the existing implementation. Are we sure this is a bug?
Charlie scenario, existing implementation
Yes, it is a bug. We can explain why with a slightly different scenario:
reward_steem_balance
is 10 Steem, and Alice'sreward_vesting_balance
is 10 VESTS.claim_reward_balance_operation
.Charlie scenario, vest when rewarded
Here's a scenario that shows correct behavior for vesting when rewarded:
1000 * 1525 / 1020.033 = 1495.05
Steem.claim_reward_balance_operation
.10 * 29.95 / 20.033 = 14.95
STEEM.Charlie scenario, vest when claimed
Here's how the Charlie scenario works out, showing correct behavior for vesting when claimed:
1000 * 1515 / 1010 = 1500
Steem.claim_reward_balance_operation
, buying 10 Steem worth of VESTS.Which is correct?
Clearly the current implementation is incorrect.
The "vest when claimed" scenario fits better with the modular blockchain, which was the original motivation for this change, as detailed in #659.