Fix wrong outgoing calculation in election

[kianenigma]

This was a very unfortunate oversight from my end; The outgoing calculation seem to have been wrong because the inputs are simply not sorted. This can then cause accounts to be immaturely deemed loser, and subject to slash_reserved().

This should be merged and deployed asap. Furthermore, I will lead an investigation over polkadot's state to make sure we can obtain a list of all accounts affected and properly reimburse them through governance.

[bkchr]

Please add a test that this never happens again.

[shawntabrizi]

@kianenigma actually it is not exactly clear to me how sorting by AccountIds matters?

Can you elaborate?

[apopiak]

ChangeMembers::compute_members_diff assumes that the inputs are sorted, I assume that's the reason.

[kianenigma]

Please add a test that this never happens again.

added.

[kianenigma]

bot merge

[ghost]

Waiting for commit status.

[xlc]

Use OrderedSet should prevent this kind of bugs

https://github.com/open-web3-stack/open-runtime-module-library/blob/master/utilities/src/ordered_set.rs

[eskimor]

Hmm, coming from Haskell. Can't we check this at the type level instead of just tests? E.g. encode the sorting requirement in the calling contract of ChangeMembers::compute_members_diff, by making it take a newtype wrapper that can only be constructed by a sorting smart constructor?

[kianenigma]

Both points are sensible improvements. I will make a follow up issue.

fwiw both Polkadot and Kusama have passed motions to refund all the immature slashing done over here. https://polkadot.polkassembly.io/motion/43

[eskimor]

There is even a crate for this, which looks sane and could be useful.