CIP-0005; Voting Meta Protocol through Broadcasts #7

Merged
merged 1 commit into from May 24, 2016

Projects

None yet

5 participants

@jdogresorg
Contributor

Nice work Ruben. ACK :)

@deweller
Collaborator
@rubensayshi
Contributor

updated with your changes @deweller

@deweller
Collaborator

ACK

@robby-dermody robby-dermody commented on the diff Apr 21, 2016
cip-0005.md
+
+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.
@robby-dermody
robby-dermody Apr 21, 2016 Member

weird line break

@rubensayshi
rubensayshi Apr 22, 2016 Contributor

it's markdown, unless I put at the end of a line it won't show as a line break and it's easier to read/edit the source this way ;)

@robby-dermody
robby-dermody Apr 23, 2016 Member

That's fine

@robby-dermody robby-dermody and 1 other commented on an outdated diff Apr 21, 2016
+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 olders can vote.
+ - `DEADLINE`: the deadline (block height or timestamp of block, see below) for the voting period (int).
+ - `STAKEHEIGHT`: the 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 seperated by a space, any other characters are allowed by for simplicity only using alphanumeric chars is recommended.
@robby-dermody
robby-dermody Apr 21, 2016 Member

let's nail this down some more. recommend -> required, or come up with an exact character set that we specify here

@rubensayshi
rubensayshi Apr 22, 2016 Contributor

I think we can allow any char (which it does atm) other than spaces, the recommendation is mostly because if you let people manually do the broadcast it requires them typing it in .. but I guess they could copy paste too.

shall I just take the recommendation out?

@robby-dermody robby-dermody commented on an outdated diff Apr 21, 2016
+
+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 olders can vote.
+ - `DEADLINE`: the deadline (block height or timestamp of block, see below) for the voting period (int).
+ - `STAKEHEIGHT`: the height at which to take the balances of `ASSET` to use to weight the votes.
@robby-dermody
robby-dermody Apr 21, 2016 Member

height -> block height

@robby-dermody robby-dermody commented on an outdated diff Apr 21, 2016
+## 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 olders can vote.
+ - `DEADLINE`: the deadline (block height or timestamp of block, see below) for the voting period (int).
+ - `STAKEHEIGHT`: the 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 seperated by a space, any other characters are allowed by for simplicity only using alphanumeric chars is recommended.
+
+##### `DEADLINE`
+`DEADLINE` &lt; 500000000 Block number at which this poll ends, &gt;= 500000000 UNIX timestamp at which this poll ends
@robby-dermody
robby-dermody Apr 21, 2016 Member

block number -> block height, for consistency?

@robby-dermody robby-dermody commented on an outdated diff Apr 21, 2016
+ - `OPTS`, followed by 2+ options, ie; `OPTS TRUE FALSE`.
+ options are seperated by a space, any other characters are allowed by for simplicity only using alphanumeric chars is recommended.
+
+##### `DEADLINE`
+`DEADLINE` &lt; 500000000 Block number at which this poll ends, &gt;= 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.
+
+The tables where the poll data is stored and any validation errors of poll broadcast messages are excluded from consensus hashes,
@robby-dermody
robby-dermody Apr 21, 2016 Member

move this to a new section near the bottom, called Consensus Hashes, or throw it into the Backwards Compatibility section

@robby-dermody robby-dermody and 2 others commented on an outdated diff Apr 21, 2016
+#### `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.
+
+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.
+
+#### Results
+Results will be `VOTE` * stake at the `STAKEHEIGHT` or otherwise the height at which `INITVOTE` is broadcasted.
+This can be on-the-fly queried from the database when fetching results.
+
+#### `LOCK`ed broadcast feed
+Counterparty has a feature to broadcast the text `LOCK` to prevent any futher broadcasts from that address ever being considered valid.
+These broadcasts are still parsed and stored, so it's possible to parse them for votes too if desired, but for now they are not!
@robby-dermody
robby-dermody Apr 21, 2016 Member

what does this mean? i.e. that voting with a locked feed works or doesn't work. the first part seems to state it will work fine, but the text "but for now they are not!" seems to negate that. please clarify

@rubensayshi
rubensayshi Apr 22, 2016 Contributor

imo they should not be, though it might mean that if some LOCKs his feed for w/e reason it means he can't vote with XCP on that address, so I guess this is an open discussion point ...

@deweller
deweller Apr 22, 2016 Collaborator

This CIP should be definitive one way or the other. Change it to something like this:

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.

(futher -> further)

@robby-dermody
robby-dermody Apr 23, 2016 Member

Yes, agreed wholeheartedly that the CIP must be totally non ambiguous. Fine with the recommended change

@robby-dermody
Member
robby-dermody commented Apr 21, 2016 edited

looks good, added my comments inline to the commit. will ACK once they are addressed

@droplister droplister commented on an outdated diff Apr 21, 2016
+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 olders can vote.
@droplister
droplister Apr 21, 2016

olders -> holders

@droplister
droplister commented Apr 21, 2016 edited

Concept NACK

If it's the case that anyone can initiate a vote, I would be against this because I don't think that's a desirable feature for asset issuers. It may be useful for XCP, which I believe is a special case, but we are on election #2 successfully conducted without this CIP when it comes to that particular special case.

For other assets, I know I wouldn't want just anyone who holds a token to be able to initiate a vote. Perhaps, I am not understanding it correctly.

There are many financial use-cases where you get non-voting right shares.

This CIP, if anyone can initiate a vote, sounds like a nightmare for asset issuers and would totally prevent the very common financial concept of non-voting right shares.

@jdogresorg
Contributor

@droplister I believe your concerns can be addressed with a simple addition to the CIP.

An INITVOTE broadcast will only be valid if it originates from the current ASSET owners address.

@droplister

@jdogresorg Such a change would make it unusable for XCP.

@jdogresorg
Contributor

I was thinking that for XCP anyone can initiate a vote, but for ASSETS, only asset owners can initiate a vote.

@rubensayshi
Contributor
rubensayshi commented Apr 22, 2016 edited

I intend to add support to the counterwallet UI to vote and display on-going polls,
my initial plan was to show 2 tabs or something with 1 being 'whitelisted votes' and the other 'all votes'.

but I suppose that would make it less useful for people because they'd have to either get their poll whitelisted in counterwallet or make the holders of their asset aware of the vote through another channel.

I think for counterwallet XCP based votes should always have this whitelisting approach, to avoid spam (could be easily used to advertise things),
maybe adjusting the above to automatically whitelist polls from asset owners and only apply the manual whitelisting to XCP and asset based polls initiated from non-owners would be good?

though to me only allowing asset based polls to be initiated by the owner sounds logical.

FYI; my main concern about the election voting is that you need a custom script (or trust blockscan) for counting votes, standardizing this would make it verifiable by anyone through the counterparty-client and also easily used by others if they want asset holders to vote on something.

@deweller deweller and 2 others commented on an outdated diff Apr 22, 2016
+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 seperated by a space, any other characters are allowed but for simplicity only using alphanumeric chars is recommended.
@deweller
deweller Apr 22, 2016 Collaborator

(seperated -> separated)

How about:

Options are separated by a space. All other (UTF-8?) characters are allowed. Using alphanumeric characters is recommended.

@robby-dermody
robby-dermody Apr 23, 2016 Member

I'm fine with that, but let's include a UTF 8 max character limit for the options. Maybe 20 or 30 character limit?

@rubensayshi
rubensayshi Apr 26, 2016 Contributor

I don't see a reason for max length, but I'm also not opposed to a 30 char max

@robby-dermody
robby-dermody Apr 26, 2016 Member

I think it's good to limit it for sanity/consistency at the UI level if nothing else, so that you can design the UIs to handle and look good with options up to that max length.

@robby-dermody
Member

@jdogresorg I'm ok with what you stated. If vote spam is an issue with XCP we could worst case limit it to specific dev addresses, but I'd personally think this should be an absolute worst case course of action... Don't like the idea of hardcoding pubkeys into the protocol...

@robby-dermody
Member
robby-dermody commented Apr 23, 2016 edited

@rubensayshi my opinion is that having a white listed and non whitelisted panes will be confusing and add extra complexity to the UI. Would rather not make such a distinction, and just nail down good rules. Eg for non XCP assets, only asset owner can make votes, and only those votes show, and for XCP, either anyone can make votes, or only certain pubkeys can make votes... (Regarding XCP rules, I favor the former, with a move to the later only happening if XCP vote spam is an issue, which I doubt it will be)

@robby-dermody
Member
robby-dermody commented Apr 23, 2016 edited

For the sake of completeness, another option is having an XCP fee for XCP poll creation. That would probably control any potential spam problem, and votes on the XCP asset could be used as well for general purpose voting, not tied to any specific asset (eg "who do you think will win the next US presidential election?").

@rubensayshi
Contributor

idk if we want to start using XCP for this, I don't think the cost for the network is higher than any other message which are all XCP-free atm.

let's restrict to asset owner, except for XCP.

I still think that we should have a whitelisted pane in counterwallet to avoid it being used to spam.

@robby-dermody
Member

Whitelisting tab/filter just for XCP, with other assets not having it due to the source restriction, right? If so, I'm good with that after thinking about it, but am curious of others opinions as well....

@deweller
Collaborator
deweller commented May 7, 2016

@rubensayshi - Can you add your most recent changes into this CIP? Or if you want to think about it more, please close this PR and submit again when you are ready.

@robby-dermody
Member

status?

@deweller
Collaborator

@rubensayshi has made the latest round of changes and updated the pull request. (Github doesn't send a notification when this happens.)

I do not see any remaining technical objections to this CIP.

I am ready to merge this.

@robby-dermody
Member

sounds good to me

@deweller deweller merged commit 48d8ca2 into CounterpartyXCP:master May 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment