Votes missing in DAO screen while proposal not established. #2708
Comments
It shows that there are no No votes.
|
|
Ah! My bad. To be honest, the dark mode is difficult for me to see with my poor eyesight. |
panleone
pushed a commit
to panleone/PIVX
that referenced
this issue
Oct 29, 2024
* Implement and use SigShareMap instead of ordered map with helper methods The old implementation was relying on the maps being ordered, which allowed us to grab all sig shares for the same signHash by doing range queries on the map. This has the disadvantage of being unnecessarily slow when the maps get larger. Using an unordered map would be the naive solution, but then it's not possible to query by range anymore. The solution now is to have a specialized map "SigShareMap" which is indexed by "SigShareKey". It's internally just an unordered map, indexed by the sign hash and another unordered map for the value, indexed by the quorum member index. * Only use unordered maps/sets in CSigSharesManager These are faster when maps/sets get larger. * Use unorderes sets/maps in CSigningManager
panleone
pushed a commit
to panleone/PIVX
that referenced
this issue
Oct 29, 2024
* Implement and use SigShareMap instead of ordered map with helper methods The old implementation was relying on the maps being ordered, which allowed us to grab all sig shares for the same signHash by doing range queries on the map. This has the disadvantage of being unnecessarily slow when the maps get larger. Using an unordered map would be the naive solution, but then it's not possible to query by range anymore. The solution now is to have a specialized map "SigShareMap" which is indexed by "SigShareKey". It's internally just an unordered map, indexed by the sign hash and another unordered map for the value, indexed by the quorum member index. * Only use unordered maps/sets in CSigSharesManager These are faster when maps/sets get larger. * Use unorderes sets/maps in CSigningManager
panleone
pushed a commit
to panleone/PIVX
that referenced
this issue
Oct 29, 2024
* Implement and use SigShareMap instead of ordered map with helper methods The old implementation was relying on the maps being ordered, which allowed us to grab all sig shares for the same signHash by doing range queries on the map. This has the disadvantage of being unnecessarily slow when the maps get larger. Using an unordered map would be the naive solution, but then it's not possible to query by range anymore. The solution now is to have a specialized map "SigShareMap" which is indexed by "SigShareKey". It's internally just an unordered map, indexed by the sign hash and another unordered map for the value, indexed by the quorum member index. * Only use unordered maps/sets in CSigSharesManager These are faster when maps/sets get larger. * Use unorderes sets/maps in CSigningManager
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It has been less than 24 hrs since my proposal was submitted to the network. As such, it is not yet 'Established'. However, there are votes that have already been made. Both these points are shown in the screen shot below of the console output. The DAO screen shown below incorrectly shows there are no votes. I strongly suspect that this is simply because the proposal is not established yet.
The new DAO screen should show the actual vote counts, even if the proposal is not yet established. Otherwise, anyone who votes during the first 24 hrs while the proposal is being established, will think something has gone wrong and their vote failed. Sure - they could check in the console, but that undermines the entire purpose of the DAO screen, which is to make things extremely user friendly.
The text was updated successfully, but these errors were encountered: