With the lack of PoW ‘voting’ by miners there’s no good way to reach / poll for consensus on changes to the protocol that aren’t completely uncontroversial.
The Counterparty Devs should be able to initiate a vote to all XCP holders (for example for a protocol change).
Being able to let all XCP owners vote on a particular issue can be very useful to poll the consensus / desire of the community.
The votes done in this way is not part of this CIP and the initial intention is not to have any protocol changes activate automatically based on these votes, though that could be a future CIP if there’s a desire to do so.
As discussed previously here: CIP: XCP Dividends for PoS voting, to avoid making anyone have more power within the protocol, we won’t be using tokens but will instead use a meta protocol with messages encoded in broadcast messages.
This also makes this easily usable for other assets.
We’ll add the code to track votes to counterparty-lib/client so that anyone can easily track ongoing votes without requiring extra scripts. We’ll also add code to counterwallet to easily cast votes, this should cover a big part of the XCP holders.
There will be 2 types of ‘special’ broadcast messages that are used for this;
INITVOTE <VOTENAME> <ASSET> <DURATION> OPTS <OPTION_1> <OPTION_N>
VOTENAME: any sequence of non-space characters used as label for the vote, must be unique across the network.
ASSET: the asset for which the olders can vote.
DURATION: the duration (in blocks) for the voting period (int) with max of 1 year.
OPTS, followed by 2+ options, ie;
OPTS TRUE FALSE.
INITVOTE is initiated a list of balances of
ASSET will be stored which will be used to weight each vote.
CASTVOTE <VOTENAME> <VOTE> <OPTION>
VOTENAME: should match a
VOTENAME that was initiated and has not expired it’s
OPTION: one of the options from
VOTE: int between 0 and 100 indicating percentage of vote.
Should there be a max on
DURATION? 1 year sounds like a good sanity check?
If a holder of a token has put a LOCK on his broadcast feed he won’t be able to vote, unless we’d ignore the LOCK (which can be done because broadcasts will still be stored with Status: invalid (locked feed))
The tables where the poll data is stored and any validation errors of poll broadcast messages are excluded from consensus hashes, to make sure this is optional and can be disabled.
I already wrote most of the code (hoping everyone will approve) and even added a
--disablepolls flag so you can run your node without parsing these messages at all.