BitShares/bitshares — pull request #987 by drltc (2014-11-14 22:53:26+00:00)
Title: Don't index retracted delegate accounts; progress on #553

THIS PULL REQUEST IS A HARDFORK CHANGE. I don't know what I should do with respect to adding compiler warnings or mention in the commit message or what.

THIS PULL REQUEST IS UNTESTED. It compiles, but I have not checked the actual run-time behavior.

This one-line change should handle retracted delegate accounts. Specifically, `chain_database::next_round_active_delegates()` calls `chain_database::get_delegates_by_vote()` which is also used by the client API to return a list of delegates by vote. In turn, `get_delegates_by_vote()` is implemented by iterating through the `_delegate_vote_index_db` database index.

When a delegate account is updated, the old record is removed from the index and a new record inserted in its place. However, if the update retracted the account, this patch will result in a new record not being inserted. Which will result in this delegate never being iterated over in `get_delegates_by_vote()`, which will result in it never appearing in `next_round_active_delegates()` result. In short, a retracted delegate account becomes ineligible for block production in future rounds regardless of having enough votes to be in the top 101. In that case, the next most popular delegate will be chosen in the retracted delegate's place.

We need to consider: What happens if we somehow get to `store_account_record` for an account that's already retracted? I think this is already impossible with @vikramrajkumar's commits in this ticket. But maybe we need to `FC_ASSERT` somewhere to prevent this case. Or maybe it's handled by the DB -- If we call `remove()` on a record that doesn't exist in the index, does the database library do the right thing?