Fix wrong deposit amount in council voters.

[kianenigma]

As pointed out correctly by @AurevoirXavier

In https://github.com/paritytech/polkadot/pull/1719/files#diff-e5e76e02c0d16e79c70b024cbe3c6ea56f3249382a0f987ba203c34fcb40ed66 we made a mistake and passed in an incorrect value (5 CENT) as the old voting bond to the migration, instead of the correct value, 5 DOLLARs.

Thus, currently all council voters have 50 milli-dots in deposit recorded for them, whereas it should be 5 DOTs.

• Do a cost analysis for the number of voters that we can support within 2 blocks, and increase bonds if needed.

[kianenigma]

Once released, I'll do another damage analysis and find the voter's who got affected by this bug (anyone who changed or removed their vote sine runtime 27) and find ways to refund them.

[gui1117]

Just wonder about https://github.com/paritytech/polkadot/pull/2562/files#r594340154
Otherwise looks good

[kianenigma]

bot merge

[ghost]

Waiting for commit status.

[kianenigma]

bot merge abort

[kianenigma]

bot abort

[kianenigma]

bot stop

[kianenigma]

bot please stop

[kianenigma]

Well, I think I can no longer stop the bot. Not a big deal. I wanted to add a further test as well, but it is fine.

[kianenigma]

bot help

[ghost]

Head SHA changed; merge aborted.

[kianenigma]

bot merge

[ghost]

Waiting for commit status.

[xlc]

maybe you need to ask nicely. i.e. sudo bot stop 😆

[kianenigma]

More description of what went wrong:

In runtime 28 (first release containing the faulty #1719), we wrote a wrong deposit amount in electionsPhragmen.voting field of all voters. The real deposit (which was already reserved) was 5 DOTs, but we recorded 50 milli-DOTs. This means that the chain had reserved 5 DOTs, but the electionsPhragmen pallet thought that it had reserved 50 milli-DOTs from all voters.

This is problematic for two reasons:

1. when you submit vote, your new deposit is calculated based on the number of members that you vote for. Then the difference of this value compared to your current recorded deposit (in electionsPhragmen.voting) is either reserved or unreserved.
2. when you submit remove_voter, the amount that you have in electionsPhragmen.voting is unreserved.

In runtime 30 we partially fixed this. We iterated over all voters, and if any of them had 50 milli-DOTs recorded as deposit, we changed it to 5 DOTs.

This means that:

• if you never changed your voting between runtime 27 and 30, then you would be fine, and you should have correct deposit values now.

• If you submitted a vote in this period (and henceforth) for the first time, then the correct deposit was set for you.

• If you submitted vote in this period, then the chain computed a value for your deposit based on fn deposit, which is certainly more than 5 DOTs, and since that value is certainly more than your recorded 50 milli-DOTs, a large amount reserved again. Afterwards, a correct deposit value is written for you. Any further interaction is then correct. The damage here is: 4.95 DOTs are potentially left in the reserved that need to be moved to free balance now. Example: Alice has 5 DOTs reserved, and the pallet thinks she has 0.05 DOTs reserved. She votes again, and the new deposit is 5.5 DOTs. The pallet should have reserved 0.5 DOTs, but in reality it did 5.45 DOTs, 4.95 of which is incorrect.

• If you submitted remove_voter, you are basically facing the last part of the previous scenario. Alice has reserved 5 DOTs, but 0.05 is recorded in electionsPhragmen.voting. When she leaves, 0.05 DOTs are unreserved, and 4.95 are left.

An easy way to approach all the above would be to check this: If you submitted either of vote or remove_voter in the [28->30] runtime version period, and your recorded deposit on-chain was 50 milli DOTs, then certainly you ended up in a bad state and some deposit amount (4.95) was lost.

---

I will conduct an experiment to make a list of accounts affected, with the amount of funds that they have mistakenly locked in their reserved balance. Any other community member who likes to replicate this and cross-check their results with mine, I'd be happy to vouch for an on-chain tip in return ;)

[emielsebastiaan]

We found 189 extrinsics of type ElectionsPhragmen.vote for polkadot runtimes 28, 29 & 30.
We found 47 extrinsics of type ElectionsPhragmen.remove_voter for polkadot runtimes 28, 29 & 30.

Data set here: https://gist.github.com/emielvanderhoek/0a6cf51393e8d22de364b777f98cd453

Please note we have not looked at nested calls, like: batches, proxies, multisig & schedules. These could theoretically have triggered council election votes too.

Lmk if this helps.

[emielsebastiaan]

Updated gist: https://gist.github.com/emielvanderhoek/0a6cf51393e8d22de364b777f98cd453

We found 49 successfully executed extrinsics of type ElectionsPhragmen.vote for polkadot runtimes 28, 29 & 30.
We found 35 successfully executed extrinsics of type ElectionsPhragmen.remove_voter for polkadot runtimes 28, 29 & 30.

[ical10]

Hi @kianenigma, I'd be happy to contribute, but as far I can digest, we will need to check those two types of actions related to voting. Am I correct?
I can start looking at the extrinsics that @emielvanderhoek provided, but then I don't know what to look for and how to do it (perhaps using calls on the js api?).
Please advise on how to proceed.

[kianenigma]

My description above is pretty clear about what we are looking for, can you tell me exactly which part of it you don't understand, or need help with?

Note that I have done an analysis myself and don't want to push you too much in the direction of replicating what I did. Instead, Ideally, I want someone else to come up with a different way of doing the analysis independently.