Skip to content

Latest commit

 

History

History
82 lines (59 loc) · 3.88 KB

cip-0005.md

File metadata and controls

82 lines (59 loc) · 3.88 KB
Raw
  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

Abstract

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.

Motivation

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.

Rationale

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.

Specification

There will be 2 types of 'special' broadcast messages that are used for this; INITVOTE and CASTVOTE.

INITVOTE

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 ASSET to use to weight the votes. if STAKEHEIGHT is ommitted then the block in which the INITVOTE broadcast 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

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

CASTVOTE <VOTENAME> <VOTE> <OPTION>

  • VOTENAME: should match a VOTENAME that was initiated and has not expired it's DEADLINE.
  • OPTION: one of the options from INITVOTE.
  • VOTE: int between 0 and 100 indicating percentage of vote.

Results

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.

Backwards Compatibility

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.

Consensus Hashes

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.

Copyright

This document is placed in the public domain.