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 issue tokens for voting to all XCP holders to initiate a vote (for example for a protocol change).
Being able to let all XCP owners vote on a particular issue by sending out a voting token and providing a list of addresses to send the token to can be very useful to poll the consensus / desire of the community.
The votes done with these tokens are not part of this CIP and the initial intention is not to have other protocol changes activate automatically based on these votes, though that could be a future CIP if there’s a reason to do so.
We will re-enable (it has been disabled in the past) sending dividends to XCP holders, but only when the source is a multisig address consisting of keys held by group of devs / board members.
Asuming the CIP is OK, the list of key holders would have to be determined by the community, to avoid unneccesary updates with key changes it’s important that the holders are active and most likely remain active in the community.
Named it CIP-0004 for now, but this is unofficial until after community discussion, feel free to submit patches against my repo:
It’s a good idea and I like it from a pragmatic point of view. However, won’t a special privilege for a few addresses lead to bad PR? Some are very obsessed with decentralization.
Alternative ways to arrange a vote are
Send vote tokens to every address with >= 1 XCP. That’s currently 3534 addresses, which will cost ~$200 in fees.
Vote by broadcast. Votes count proportional to XCP balances at a specific block. This worked well for the CP Foundation election.
I’m glad you mention this. Obviously it’s complex and for the future, but having some key parameters set automatically by votes would be very beneficial. The asset issuance fee could be set by votes. It would be good for smart contract limits too, I guess.
– EDIT: Maybe the best solution would be to enable dividend to XCP holders for everyone, with a high XCP fee?
I agree that the idea of someone having some form of extra control isn’t amazing, but it’s very minor and I personally wouldn’t mind.
I think ‘manually’ sending the token to each XCP holder through singular transactions is too costly and it will only increase.
voting by broadcast and counting proportional to the XCP balances would be a good option too!
however how would we initiate a vote?
and would the software counting the votes (and freezing the balances when the voting period starts) then be a small seperate script?
we could maybe build into counterwallet an easy UI with list of active votes and you can cast a vote through a broadcast from there (easy to update to, doesn’t require any1 other than Robby to update)?
other wallets could easily add the same feature into the UI of their wallet and the maintainer of the wallet would be responsible for updating the list of active votes.
and make a small script that allows everyone to reproduce the counting of the votes.
I thought the disabling of XCP dividends was done after the board election and that the board election still used it, good to know it the actual facts
I could add something to counterparty-lib that tracks votes based on contents of a broadcast, for example:
broadcast text=INITVOTE XCPELECTION XCP 4000
would initiate a vote for all XCP holders within the next 4000 blocks called ‘XCPELECTION’ and store a list of frozen XCP balances at the height of this broadcast.
and then anyone can broadcast text=DOVOTE XCPELECTION to cast their vote and counterparty-cli can display a list of votes with their XCP weight taken into account.
that way everyone can list all current votes going on and their results and anyone can initiate a vote.
as a result if you list the votes there might be some spam … but because it’s not with actual tokens it’s less obnoxious.
and a wallet could list all open votes or a subset that’s hardcoded into the wallet itself (again moving the responsibility to the wallet to choose which votes to display or not instead of baking it into the protocol).
I head you liked metaprotocols? so I put a metaprotocol in your metaprotocol?
hmm for my information; if someone LOCKs his broadcast feed he’s never able to broadcast anything ever again right?
I think once a positive value is broadcast, that broadcast feed is closed, but a new broadcast can be initiated from the same address, using a negative value.
I’m testing it now. WiIll update here as soon as i find out
RESULT: An address with locked feed can still broadcast messages and values. The ‘lock’ only prevents the values from resolving bets, I suppose. Explore Decentralized Web
Why build into the protocol? I don’t remember there being any issues voting via broadcast for the community director positions. We could expand the URI schema CIP (https://github.com/tokenly/cips/blob/master/cip-0002.md) to include broadcast voting to set a standard for wallets to use.
however as soon as a LOCK broadcast is send no futher broadcasts will ever be proccessed / accepted, which would lock someone out of being able to vote…
would you guys want with some code in counterparty-lib/client to parse vote broadcast msgs and be able to list them?
or you guys feel it should only be a seperate script and only some additions to counterwallet?
the hard part is freezing the balances at the moment the vote is initiated and make sure other ppl can (easily) reproduce that, for a seperate script that would require someone to reparse the blockchain up to a particular block and then query the balances, when it’s integrated into counterparty-cli/lib it can do that automagically.
however the disadvantage is that you could have a big list of different votes going on because ppl use it to spam …
This broadcast was sent after the address was locked. The message and value still shows up. LOCK only locks bet settlement, not the broadcast itself.
However, an issue with voting through broadcasts is that active oracles will settle bets unless the value is less than -3, in which case the value does not influence any bet. This concern is negligible though. There are no active oracles and an oracle does not need to hold XCP anyway.
hmm, it’s marked “Status: invalid: locked feed”, but if we’d ignore that, how did you manage to do that?
because broadcast.compose requires broadcast.validate to return no errors and it does … ?
I use CounterTools.
Maybe it’s your client that won’t let you broadcast from a locked address?
I think initially the devs designed broadcasts for oracles/feeds. Lately it’s being used for everything except feeds
yea, counterparty-client / counterwallet won’t let me, and it shouldn’t because the broadcast is invalid …
the only reason it shows up is because we store invalid messages (sends, broadcasts) for (to me unknown) reasons too, but it’s definetely not considered valid.
My node is reparsing, but I’m curious if the LOCK functionality is used for anything other than bets or if the code should be updated to specifically only LOCK the feed for betting…?
but we’re getting off-topic; I’ll create a new topic for discussing the LOCK stuff cause either I’m missing something or something isn’t right here!
back on-topic;
would you guys want with some code in counterparty-lib/client to parse vote broadcast msgs and be able to list them?
or you guys feel it should only be a seperate script and only some additions to counterwallet?
the hard part is freezing the balances at the moment the vote is initiated and make sure other ppl can (easily) reproduce that, for a seperate script that would require someone to reparse the blockchain up to a particular block and then query the balances, when it’s integrated into counterparty-cli/lib it can do that automagically.
however the disadvantage is that you could have a big list of different votes going on because ppl use it to spam …
Storing invalid txs happens with dex tx types too, I think that should probably be addressed first. Not really sure why they’re stored at all except for maybe testing purposes.
Regarding freezing the balances at a particular block, you could query the balances, debits and credits tables to determine the asset balance at a particular address at any given block. No need to reparse the blockchain. That could even be written into an API call with address, asset and block as the inputs.
I think betting on sidechains is a bit long term xD
It’s not a whole lot of work to build it into counterparty-lib/client, the question is if people are OK with building it into it or would prefer to see it as a seperate script that requires some manual config to get the voting results.
Regardless of the above choice I’d build the voting part into counterwallet.
It seems easier to have this built in so that there’s a way for everyone to do a check (specifically related to the state of token ownership at a point in time) on their own.
Actually - now that I mention it - it would be nice to provide a way to get token distribution by address at a point in time (or at given block height) as part of this command. Where this came up several times was people would - technical difficulties or other - not pay out dividend on time and there’s no easy way for them to tell what was the status in the past. I think various voting would also require that users be able to not only determine, but also display at will, who was supposed to have the right to vote and how many votes - vote auditing of sorts. Today if you have a token-holder meeting and everyone lists holding addresses, it’s easy to agree who was supposed to vote and broadcast a hash of the list of addresses.
But if you finish the meeting and want to see who owned what just before the meeting begun (to prevent front-running of meeting conclusions for example), it is not easy. Also you may need to send voting tokens (or announce qualified broadcast addresses) to the holders at the time before the meeting started, which may be different from the current list.
One part that bothers me a bit is that there is no good way to eliminate stock exchange holdings, but I guess who wants to vote may need to withdraw their tokens to a controlled address if they want to be able to vote.
Edit: I am thinking about the equivalent of “SELECT address FROM balances WHERE asset=‘LTBCOIN’ AND block_height=‘390000’” which isn’t possible to do in a straightforward way in SQLite either.
