-
Notifications
You must be signed in to change notification settings - Fork 355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend threshold types for multisig #139
Comments
Now reviewing. |
When reviewing this I found what I think are some inconsistencies, or maybe a misunderstanding on my part. Posting here so we can discuss before submitting the review. When you say:
That seems contradictory with the comments in the
The example in particular, seems to imply that And, looking at the code, you're using in fact the initial (snapshotted) weight. Probably more important: if the percentage is over the initial weight, then the fairness of the voting scheme is easy to defeat. Just submit a proposal associated to a group with a small number of members (one (the proposer) will suffice), and add members to the group afterwards. Given that the initial total weight is computed as a sum of the members' weights at proposal creation, any new member or members with enough weight can easily pass the proposal; since new member weights are not considered when computing the "total" weight. |
That comment refers not to one proposal but the lifetime of the contract. Proposal 1 starts with total weight 100. Proposal 2 with total weight 200. In absolute count, they would need the same number of yeses to pass. In absolute percentage, the second one would need more. Maybe I should clear up the texy |
The same with the other threshold, i.e Let's clarify this first, so I can make a useful review. |
As to the attack, the last 4 tests thoroughly show that they use the voters weight from the snapshot. (Make a proposal. Change voters, do some votes, ensure the original weights were used) |
Every proposal uses snapshots of total weight and individual voter weights (the second is done in the cw4 contract) |
AH, OK. You're using the snapshotted weights of the members too! That's the root of my confusion: I understood that only the total weight was being snapshotted. |
Thanks for clarifying... this shoud have been clear after our work in snapshots, but I somehow got confused by the apparently contradictory comments. |
I did the whole weight snapshotting a few prs ago. The point was not how voting worked, but that the number of votes needed to pass can change automatically as the group changes. Unlike the first, simple version (only really suited for relatively static groups) |
Yes, that was really confusing to me. |
Happy for any proposals of better documentation. I have the picture in my head and often forget to write it all down. |
Sure. That will be part of the review. |
I'm finding it exceedingly difficult to know what is the correct impl in each case. We'll have to document this better, or after a couple of weeks nobody will understand how it works in detail. |
Note for future readers. We did do quite a bit of documentation improvement before merging. See #188 |
Builds on #80
Currently the
cw3-fixed-multsig
only supportsAbsoluteCount
threshold, and the initial version ofcw3-flex-multisig
as well. Let us extendcw3-flex-multisig
to support all three threshold types defined in cw3.This should snapshot total_weight at the beginning of the vote, and calculate acceptance criteria based on that. (Note: there may be a subtle difference between the snapshotted member weights - beginning of the block when proposal was created - and the total weight - beginning of the tx when the proposal was created. We can make a follow up issue to see how to resolve that).
These votes (like percentage and quorum) must work properly with significant membership changes during the election.
The text was updated successfully, but these errors were encountered: