Critical Consideration For TCR’s that use Partial Lock Commit Reveal Voting in Conjunction with Minority_Bloc_Slash about tcr

[eduardo-munoz]

Although it is true that there are a max number of polls equal to 100/MBS, token holders won't always be voting with their entire funds. Rationale behind voters not using the entirety of their token holdings to vote includes the uncertainty they have in winning the vote. If they are uncertain, they will be less willing to vote with the entirety of their token holdings as they will end up losing more tokens if they lose.

I propose that voters have the MBS percentage of their votes locked until the end of each vote. For example, if MBS is 10%, and a voter commits 100 tokens to vote, then 10 tokens are locked for the entirety of the voting period, with 90 unlocked to be used across other polls. An outlined example can be found here.

This solution allows for users to vote simultaneously across polls with the same tokens, while guaranteeing that they can forfeit tokens if they're on the losing side, regardless of the MBS percentage.

[GNSPS]

👏 Totally in favor! 😄

[GNSPS]

I'm not really sure about the chronological slashing... Shouldn't the slashing still be equal to 10% of the stake or 10% of the balance, whichever's the smallest (a min function basically)?

I think it would be more sensible to implement a maximum of polls in which a token holder can vote simultaneously:

Max_simulPolls = 100 / MINORITY_BLOC_SLASH

It would solve both the edges cases presented above.

[Ethereum1227]

Ya, that would be easier to implement.

[skmgoldin]

Closing this because it isn't implemented in this repo.