CIP: 5 Title: Voting Meta Protocol through Broadcasts Authors: Ruben de Vries Discussions-To: https://counterpartytalk.org/t/cip-proposal-voting-meta-protocol-through-broadcasts/1926 Status: Draft Type: Standards Created: 2016-03-21
Any user should be able to initiate a vote for all holders of a Counterparty asset. Holders of the asset can broadcast their vote and all Counterparty nodes can tally the votes.
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. Using this proposed protocol, Counterparty developers can initiate a vote to all XCP holders to learn the will of the community.
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 in the community, 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> <DEADLINE> (<STAKEHEIGHT>)? 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 holders can vote.
DEADLINE: the deadline (block height or timestamp of block, see below) for the voting period (int).
STAKEHEIGHT: the block height at which to take the balances of
ASSETto use to weight the votes. if
STAKEHEIGHTis ommitted then the block in which the
INITVOTEbroadcast is confirmed is used.
OPTS, followed by 2+ options, ie;
OPTS TRUE FALSE. Options are separated by a space. All other characters are allowed. Using alphanumeric characters is recommended.
DEADLINE < 500000000 block height at which this poll ends, >= 500000000 UNIX timestamp at which this poll ends
(same as bitcoin nlocktime).
A maximum of 1 year (31536000 seconds or 52560 blocks) is enforced as a sanity check.
CASTVOTE <VOTENAME> <VOTE> <OPTION>
VOTENAME: should match a
VOTENAMEthat was initiated and has not expired it's
OPTION: one of the options from
VOTE: int between 0 and 100 indicating percentage of vote.
Results will be
VOTE * stake at the
STAKEHEIGHT or otherwise the block height at which
INITVOTE is broadcasted.
This can be on-the-fly queried from the database when fetching results.
LOCKed broadcast feed
Counterparty has a feature to broadcast the text
LOCK to prevent any further broadcasts from that address ever being considered valid.
Any vote from a address with a
LOCKed broadcast feed will be ignored.
This is completely backwards compatible with older clients as we're using valid broadcast messages. As described the poll data will be excluded from consensus hashes to avoid a split.
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.
This document is placed in the public domain.