Our best source of a timestamp is the bitcoin block timestamp. But it can be off by around an hour or so.
But, for a 30 day voting period that you want to end at 5 PM EDT, you can get a lot closer with a Timestamp +/- 1 hour than you can by guessing the number of blocks.
@rubensayshi - what do you think about allowing both a timestamp OR a block as the DEADLINE option? Bitcoin already does something similar. If the amount is less than the current timestamp, interpret the value as a block height. Otherwise, interpret it as a unix timestamp.
updated proposal and code to have a DEADLINE instead of DURATION:
DEADLINE < 500000000 Block number at which this poll ends, >= 500000000 UNIX timestamp at which this poll ends (same as bitcoin nlocktime).
1 Like
Great.
Have you written up a CIP yet for this? I’ll look it over and merge it in as a draft.
@droplister I disagree with your statement. The fact that I registered 15 domains thru whatever registrar doesn’t, and shouldn’t, entitle me to management (or voting) rights in the registrar matters (and upstream entities, if any). CP is not completely the same - you can’t move a CP asset to Omni, for example, as you can transfer your domain elsewhere - but IMO the difference is not significant enough to warrant the voting based on the number of assets owned.
Disenfranchising a dev and token holders isn’t going to make you better off. There must be some sort of a governance mechanism. There’s no best way to go about it, there are only bad and less worse ways to institute it.
I can live with the idea that each asset issuing address gets 0.5 votes per each asset owned (as in, the address owns the asset, not a token or fraction of it.)
In the first portion of your response, you are arguing against points I didn’t make.
I’m simply pointing out that I have a stake in XCP, but not as measured here.
Though it was not my original argument, I will add that owning an asset is more of a stake than holding a token that may, potentially, at sometime in the future, be used to register an asset. The XCP token is easily bought and sold and may only represent a temporary stake. Owning an asset is a commitment for as long as XCP as a protocol is used.
Additionally, I reject most comparisons to domain names and I will have to question your fundamental understanding of the domain name system.
We don’t want governance. We want a working Counterparty. It works. Stake voting is stupid.
@deweller I linked it to you in slack before I submitted it here afaik; https://github.com/rubensayshi/cips/blob/cip-0005/cip-0005.md and code: https://github.com/rubensayshi/counterparty-lib/pull/3
@droplister @something as shortly discussed on slack it’s not hard to account for the registration of an asset in this, though ti would be hard to account for transfering of the ownership of the asset.
I could already add the first (easily, 2 lines of code) and add the 2nd as an future goal / ideal situation to the CIP?
1 Like
Looking good. Here is my feedback.
Consider adding something like this in the STAKEHEIGHT description:
If `STAKEHEIGHT` is ommitted then the block in which the INITVOTE broadcast is confirmed is used.
For these items:
Should there be a max on DEADLINE? 1 year sounds like a good sanity check?
Go ahead and make the decision and update the CIP to reflect your decision. We can discuss here if you want more input.
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))
Same here. Go ahead and state this as a fact however you want it to work or discuss here.
Can you clarify what makes a valid OPTION? Spaces, for example, may not be allowed. How about special or non-ascii characters?
updated, options are seperated by a space, anything else is OK, but I added “options are seperated by a space, any other characters are allowed by for simplicity only using alphanumeric chars is recommended.”
1 Like
Can you fix the extra ` here:
…block in which the `INITVOTE`` broadcast is…
There is a typo at:
As describe the poll data will be
Should be: As described
Lastly,
What do you think about updating the Abstract and Motifivation to be a little more general? Like:
Abstract
Any user should be able to initiate a poll for all holders of a Counterparty asset. Holders of the asset can broadcast their vote and all Counterparty nodes will 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.
1 Like
I’m setting a date target of April 29th to merge this CIP as a draft. Please ACK/NACK on the PR at https://github.com/CounterpartyXCP/cips/pull/7.
1 Like
@droplister
Continuing your discussion from the PR.
Right now anyone can initiate a vote for any asset by asking people to broadcast their result. All this change does is make it easier for people to track these votes by using counterparty server instead of writing a website script to do it.
Can you elaborate with a specific example as to why this is bad?
1 Like
Like I said, non-voting right shares are a real and useful thing. I would like to see Counterparty assets used in corporate governance, for example. Or, say you have a crowd equity model, does someone who put $10 into the hat really have voting rights? So, there’s the non-voting right thing. There’s also why you may want people to have non-voting rights: hostile takeover. In Counterparty, I suppose that looks slightly different than it does today in normal corporations, but the concept is similar. You can create hostile votes, start a referendum on the asset owner, and impeach their reputation publicly & immutably.
For example:
“Is SJCX a scam?”
“Should Shawn Wilkinson step down?”
This feature is obviously bad for asset owners, in my opinion, if just anyone can start a vote. I like the DEVPARTY model (Vote tokens are distributed to a specific list of holders allowing you to have voting and non voting rights) or distributing a VOTETOKEN dividend (For which I believe there is a fee per recipient to prevent spam). With this CIP, I can cheaply graffiti anyone’s asset, squander reputation, change minds, and do all sorts of stuff at the expense of the asset issuer.
1 Like
I merged CIP-0005.
All remaining technical objections were addressed by the author (Ruben).
This is a standards track CIP in draft status. This means that the CIP is technically feasible and makes sense.
The next step is to see an implementation and then determine if this implementation should be included in a future Counterparty release. Once it is slated for a future Counterparty release, it will be marked as Accepted. If it will not be slated for a future release, then it will be marked as Rejected.
If it is accepted, then once it becomes shipped it will be marked Final after an amount of time where it looks unlikely to be modified.