As I understand it, the voting runs forever and is intended to give everyone feedback of what the stakeholders support. So we see currently 34% of the stake weight is voting to end digging, and 66% of it isn't.
I understand waiting a week or more however:
I don't get it. How can any fair voting system take into account those who don't vote? When you say "66% of it isn't" is that not an incorrect statement if it is intending to mean they are against petition 5afa074c? Even direct abstain votes does not mean they are against any specific petition.
So this is starting to sound like there has never been any intentions to act on what the greater
clam voting community wants. Emphasis on "clam voting community". Those who don't vote, typically don't want a voice and as is in any truly
fair voting system, they are not taken as part of the voting tallies. Else it calls to question the clamour voting system in general (or any voting system to take such an approach).
As for the developers and massive premines, that is a null issue. If this vote was never intended to be acted on, as it is becoming clear, and tallies are based on non voters...then we have exactly what the initial distribution has shown us: An unfair system that does not support the vast number of newcomers to crypto, rewards criminals who in the past have setup fractional reserve systems and scammed the greater BTC/LTC/Doge community. Exposes anyone who presently supports the greater clams community as we have recently experienced. To quote the old lady in the commercial "None of this makes any sense."
What really makes me smile is the moniker of "fair distribution"
This whole voting is...well,...a bit fishy. What am I missing?
You are thinking in terms of 'voting'.
This is counter-intuitive and nuanced, but important: CLAMour is not a 'vote', but an expression of support.
In terms of our consensus network, it is a way to gather data on support for changes.
This same process would conventionally be completed via stakers reporting an update during a triggered fork (and likely still will, even given a CLAMour consensus).
The difference is that we are able to gauge this support in real-time and it can guide the conversation BEFORE an update has been painstakingly developed.
This is why the CLAMour system doesn't have defined start/end dates.
It was designed around the pattern of a triggered forking change.
An idea must convince the network that it is a secure and positive change.
Essentially, a staker expressing support for a CLAMour petition is symbolically reporting that they would update to implement the change.
This is preferable to the alternative: develop a forking change without this symbolic support and simply "hope" that everyone updates.
Since we are simulating an update-triggered forking change, those blocks staked which do not specifically support the change are by definition a stake in support of the status quo.
It allows us to speak intelligently with common terminology about actual provable data.
This is preferable to the alternative: arguing about who has the "support" of the network, without any definition or data on what "support" means.
We designed CLAMour around two core principles: that it be permission-less and provable.
Anyone can start a CLAMour petition, there are no rules concerning what is or isn't acceptable.
The fact that there are no start/end dates allows an individual or group to evangelize and convince others to join in and support the petition.
The "bus" rule necessitates that we try to ensure CLAM is resilient.
It would allow, for instance, a group of users to evangelize for a change which is not agreed to by the core development team.
Because of CLAMour, these users would have a method to prove to the community that there is widespread support for the change.
Those users could then release an update, without approval, and feel confident that the update would gain consensus on the network.