Stake weighted voting system

[dexX7]

Given the recent discussion about BTC integration, it would actually be nice to have some kind of vote mechanism within the protocol.

There are probably a few ways how this could be done:

Method 1: signature based

• A snapshot of all balances at time t is taken.
• A webform is created where users are required to sign a message (e.g. "I agree" or "I vote against") with their MSC related address(es).
• Based on the balance snapshot votes are weighted according to their holdings.

Upsides:

• No new infrastructure required.
• Zero transaction cost.

Downsides:

• It's centralized.
• My experience with the faucet showed one thing: most users didn't use such a mechanism and even the authentication via an one-time-string which is put into a bitcointalk.org forum profil is more popular.

Both downsides may be mitigated by providing proper education and easier to use tools. Instead of the standard route of using Bitcoin-Qt to sign a message, a standalone script might be used to sign the message and upload the signature to a server. The signed messages/signatures could be published, so everyone could reconstruct and at least to some degree verify the results.

---

Method 2: vote tokens

• Two smart properties are created: one which represents a "yes" vote, another one which represents a "no" vote.
• The total number of tokens is based on the total amount of MSCs.
• Every MSC holder receives a bunch of both tokens proportional to their MSC holdings. The amount of "yes" and "no" tokens is equal.
• Users vote by sending the vote tokens to a predefined address. The final balance represents the voting result.

Upside:

• Also no new infrastructure required and technically doable right now.
• No central authority which counts votes.

Downsides:

• Transaction costs (I'll try to provide some numbers on this later)

MaidSafeCoin probablay helped a lot to boost SP usage, so I assume this method is much easier than method 1. The downside mentioned here is a general one and does also apply to similar types of tokens like "invitations", "coupons" etc., but since the transaction cost is fixed and not linked to the quantity of sent tokens, participating may be unfavorable for users with smaller holdings.

There is something very interesting related to this method: tokens can be transfered - to anywhere! Votes could be given away to other people or even traded. I'm not sure, if this is a good or bad thing, but certainly it's something I'd love to observe in some real life context.

There is another related topic: transparency. Since transactions are immediately visible on the blockchain, the knowledge about (partial) results may influence voting behavior. I'm also not sure, if this is a good or bad thing.

---

Method 3: ????

How else could this be done? What's your general opinion about this topic? And in particular: what's your opinion about this in context of the question about BTC usage within the Master protocol? Do you think we should do a vote on this or simply discuss and draw own conclusions?

The more I think about this, the more I'm convinced this may be a very special opportunity -- of doing one of the first votings of this kind! :)

[ripper234]

I think that MSC are the vote tokens (any derived currency also act as vote tokens in their separate namespace).
I propose three new messages:

• Create ballot, containing a textual message and a block height.
• Cast vote, that votes with MSC on a particular ballot. If a specific set of MSC tokens have voted alreday, they can change their votes by signing again. The vote automatically expires at the given block height. Tools (web/desktop) can be built to parse the blockchain and display ongoing votes and completed votes.

An essential part of this system is a 3rd operation:

• Delegate vote - Instead of voting myself, from now until changed, another MSC address owns 'my voting power'. This allows for people who don't want to vote on every decision to still be involved in the voting process by delegating their power to someone else. At any point in the future they are free to change or cancel their delegation.

[dexX7]

I do like the idea of adding a vote mechanism on the protocol level, at least to avoid the requirement of countless sends and so on.

For this case I played it through with two user created tokens. One represents a "yes" vote and one represents a "no" vote. Smart propertys are transferable and the infrastructure to do so already exists.

Vote tokens are issued for every (smallest possible unit) sMSC and distributed to the users whereby the amounts are chosen proportional to their MSC balance. There should be a fixed deadline and by sending those vote tokens to a specific address users can participate in a vote.

The token type ("yes", "no") with the higher balance determines the result.

---

The data I pulled from masterchain.info probably excludes reserved balances, but nevertheless to begin with some data about Mastercoin holders (transaction cost calculations are at the bottom):

The top    17 Mastercoin addresses account for 50.4227 %.
The top   110 Mastercoin addresses account for 90.0275 %.
The top   205 Mastercoin addresses account for 95.0231 %.
The top   350 Mastercoin addresses account for 98.0112 %.
The top   444 Mastercoin addresses account for 99.0029 %.
The top   816 Mastercoin addresses accoutn for 99.9001 %.
The top 1,242 Mastercoin addresses account for 99.9990 %.

The sum of all balances is 585,208.50458803 Mastercoins.

 119 addresses hold at least 500.0    Mastercoins.
 340 addresses hold at least 100.0    Mastercoins.
 432 addresses hold at least  50.0    Mastercoins.
 667 addresses hold at least  10.0    Mastercoins.
 787 addresses hold at least   5.0    Mastercoins.
1108 addresses hold at least   1.0    Mastercoins.
1165 addresses hold at least   0.5    Mastercoins.
1354 addresses hold at least   0.005  Mastercoins.
1694 addresses hold at least   0.001  Mastercoins.
2174 addresses hold at least   0.0005 Mastercoins.

There are 2,761 non-empty Mastercoin addresses.

Sum of holdings in % vs. number of users (0-95 %):

Sum of holdings in % vs. number of users (95-99.999 %):

Sum of holdings in % vs. number of users:

---

Even though confirmations are not instant, the ongoing test with the faucet shows: using minimal output amounts such as 0.00000546-0.00000684 BTC is sufficient to spread a transaction whereby a fee 0.0001 BTC needs to be attached nevertheless. I have no concrete data yet, but it appears a transaction like this takes about, but not more than four hours to confirm. This should be fine for this application.

The cost for one simple send transaction consists of the following amounts:

0.0001     BTC transaction fee
0.00000546 BTC sent to the Exodus address
0.00000684 BTC to encode a simple send transaction
0.00000546 BTC for the receiver reference

That's a total of 0.00011776 BTC for one transaction. Assuming two tokens are used, the cost to distribute the vote tokens to one address is therefore 0.00023552 BTC.

Distributing two vote tokens to the top 1242 addresses which represent 99.999 % of all Mastercoins would cost 1242_0.00023552 = 0.29251584 BTC and distributing two vote tokens to all 2761 non-empty addresses would cost 2761_0.00023552 = 0.65027072 BTC.

To maximize activity it may be considered to add enough BTC so that any user can vote without funding his wallet:

0.43877376 BTC (1242/2761 addresses reached, enough BTC attached to use one vote token)
0.58503168 BTC (1242/2761 addresses reached, enough BTC attached to use both vote tokens)
0.97540608 BTC (2761/2761 addresses reached, enough BTC attached to use one vote token)
1.30054144 BTC (2761/2761 addresses reached, enough BTC attached to use both vote tokens)

[taariq]

Thanks dexX7. This is very helpful data and a stake-based voting system
would be extremely helpful to guide protocol decision making process. Great
analysis.

[ripper234]

Helpful stats as always dexx, tnx.

The reason I don't think this should be done as a separate token is that I want the voting power to always be 'callable' to the owners of MSC.

If I don't actively participate in voting, but I trust Taariq to vote on my behalf, I want to send him my vote power/token ... but as soon as I sell my own MSC that vote token should be reset to the new owner of these MSC. I think using smart property for this is convoluted and more complicated than a brand new feature custom tailored for this.

[Bitoy]

An easier ways to vote is to establish a yes, no and proxy vote address.

From your msc address send dust to the yes vote address if you agree.

From your msc address send dust to the no vote address if you disagree.

From your msc address send dust to the proxy vote address, and your
designated proxy address.

Ex.
yes votes
Address1 total msc 100
address2 total msc 39

No votes
Address3 total msc 50

Proxy vote
Address4 total 200 msc proxy is Address3

Winner is "No" 250 votes vs "Yes" 139 votes

On Sunday, June 1, 2014, Ron Gross notifications@github.com wrote:

Helpful stats as always dexx, tnx.

The reason I don't think this should be done as a separate token is that I
want the voting power to always be 'callable' to the owners of MSC.

If I don't actively participate in voting, but I trust Taariq to vote on
my behalf, I want to send him my vote power/token ... but as soon as I sell
my own MSC that vote token should be reset to the new owner of these MSC. I
think using smart property for this is convoluted and more complicated than
a brand new feature custom tailored for this.

—
Reply to this email directly or view it on GitHub
#178 (comment).

[dexX7]

I want the voting power to always be 'callable' to the owners of MSC

You actually could send Tariq your vote tokens, if you prefer he votes on your behalf. I see where you are getting related to MSC sells - so basically instead of saying "because at time X (in the past) you held 1000 MSC and therefore you were granted the vote rights worth of 1000 MSC" you say "at the very moment of voting you hold 1000 MSC and therefore your vote is worth 1000 MSC"? Would probably be doable, but seems quite more complex, because it would be required to verify votes over and over again - at least how I understand it right now.

An easier ways to vote is to establish a yes, no and proxy vote address

Sounds similar whereby the step of "create vote tokens" and "distribute vote tokens to the users" is skipped. This would save the initial cost of distributing vote tokens at the cost of being not backwards compatible, so to speak, because it wouldn't be sufficient for a client to support SP, but the client would need to "know about the vote" to credit the user with vote rights. If you solely say "any dust sent to address X at a specific time" but without any form of token or vote representation, the vote rights wouldn't be transferable.

From a cost perspective it almost doesn't matter for an user, if he performs a class B simple send transaction with some tokens or if he uses a new transaction type, let's say for example an "OP_RETURN transaction with 1 in the output" casts "yes" and "OP_RETURN transaction with 0 in the output" casts "no" -- the expensive part are the miner fees, not the output values. (0.00010000 BTC for fees only vs. 0.00011776 BTC for a simple send transaction -- assuming accepted values of v0.9.x are used)

Note: I used smart property and vote tokens, simply becaue they are available right now and they seem to offer all properties that may be desired -- being easily trackable (e.g.: final balance: 9392 "yes tokens", 1343 "no tokens") and transferable, not only to the "ballot-box", but also between users.

With a protocol addition, I think I'd chose smart property based vote tokens nevertheless due to the properties I mentioned right now, but I would try to skip the step of the initial distribution via many simple sends. Actually there is already something we'd might use for this scenario: tx type 3: send all

[ripper234]

Yeah I want holder per MSC at time T to be able to vote at time T (directly or via proxy).

I still don't understand how a system with separate tokens can accomplish this.

[dexX7]

Ah, got it. You're right, that's not possible via SP. :)

In the case of token based voting I would announce the moment on which a snapshot of all balances is taken beforehand, so anyone who likes to increase their MSC holdings for this purpose can do so. Let that moment defined by a block height in the future for example. At this specific height the state of all balances would be saved and tokens distributed according to the balances at this point. After the initial distribution there would be a periode in which those tokens may be used to vote or to be transfered to other users. After the deadline (which is also announced at the beginning) of the vote no additional incoming tokens "count".

Question: what would be won, if votes are only considered as valid and weighted based on MSC balance at time T? For similar transparency I'd announce this specific time in before, too, but the downside I see here is that users would be required to hold their MSC during the whole periode of the vote to not invalidate their voting rights.

[Bitoy]

Sorry I thought it is a one time voting for msc only.

To make it a protocol voting system available to all asset (currency id), we can create a vote tx.
CurrencyId
Proposition text 80
Start date
Deadline

Ex.
Currency id =1 (for msc)
Proposition = "should we allow direct btc to metacoin dex"
Start Date = 6/5/2014
Deadline = 6/12/2014

Send to exodus address

Tx is valid if the following are true
Start address must be greater than block date
Deadline must be greater than start date
Currency id must be an existing currency id.

Only votes received after the start date and before the deadline is accepted.

To vote a user can just send a dust to the "yes vote address", "no vote address" or "proxy vote address"

No. Of Votes are counted based on the number of currencyid a user has at the deadline.

[dexX7]

Good you mention it, Bitoy. It would indeed help if there were a transaction which defines the parameters of a vote, e.g. start, end and topic to vote on. The later raises an interesting question: where is this stored? I think we should keep the actual data put in the block chain as low as possible and rather work with external references like a link to a longer description, if needed, as well as a hash over the content, so it's visible, if content was changed.

I furthermore realized votes are not necessarily binary -- it's not always "yes" or "no", but may be a pool of several choices.

Let's boil this down. What's the minimal requirement we'd need? I see it this way:

1. Some way to define parameters -- the great thing, such a transaction is not consensus critical, but rather an additional feature. Maybe this can be generalized to "meta data".
2. I suggested to use tokens as representation of votes to lower the need for changes. Let's not have a new transaction type for every new thing, because ultimately smart properties should be used for general stuff and not only as "coins", right?
3. A way to "credit" everyone with tokens or vote rights.

Furthermore up to discuss: Ron's post about the mechanism itself. Edit: this is also related to the question, if tokens are used or some kind of "I vote X" type of transaction.

[dacoinminster]

I also prefer not to issue "voting tokens", since if buy MSC, I should also
be buying the right to vote on anything which MSC people care about. \

Security question: what about coins in cold storage? I would be loath to do
a send from an address in cold storage to transfer voting rights, since
that makes my offline storage less secure (by publishing the public key,
and even physically by just accessing the funds). I'm not sure I WOULD risk
accessing MSC in cold storage unless it was a REALLY important vote.

I think we do need custom commands for this:

1. Create issue to vote on, with up to N choices, and the currency which
   can vote
2. Vote on an issue
3. Transfer voting rights to another address

This also implies UI work to display active votes, create these tx's, and
so on. I think this feature is a bit further down the roadmap than most of
the other features.

On Mon, Jun 2, 2014 at 6:03 AM, dexX7 notifications@github.com wrote:

Good you mention it, Bitoy. It would indeed help if there were a
transaction which defines the parameters of a vote, e.g. start, end and
topic to vote on. The later raises an interesting question: where is this
stored? I think we should keep the actual data put in the block chain as
low as possible and rather work with external references like a link to a
longer description, if needed, as well as a hash over the content, so it's
visible, if content was changed.

I furthermore realized votes are not necessarily binary -- it's not always
"yes" or "no", but may be a pool of several choices.

Let's boil this down. What's the minimal requirement we'd need? I see it
this way:

1. Some way to define parameters -- the great thing, such a
   transaction is not consensus critical, but rather an additional feature.
   Maybe this can be generalized to "meta data".
2. I suggested to use tokens as representation of votes to lower the
   need for changes. Let's not have a new transaction type for every new
   thing, because ultimately smart properties should be used for general stuff
   and not only as "coins", right?
3. A way to "credit" everyone with tokens or vote rights.

Furthermore up to discuss: Ron's post about the mechanism itself.

—
Reply to this email directly or view it on GitHub
#178 (comment).

[dacoinminster]

Oh, and creating issues for voting needs an anti-spam fee (burning MSC)!!

On Mon, Jun 2, 2014 at 5:13 PM, J.R. Willett jr.willett@gmail.com wrote:

I also prefer not to issue "voting tokens", since if buy MSC, I should
also be buying the right to vote on anything which MSC people care about. \

Security question: what about coins in cold storage? I would be loath to
do a send from an address in cold storage to transfer voting rights, since
that makes my offline storage less secure (by publishing the public key,
and even physically by just accessing the funds). I'm not sure I WOULD risk
accessing MSC in cold storage unless it was a REALLY important vote.

I think we do need custom commands for this:

1. Create issue to vote on, with up to N choices, and the currency which
   can vote
2. Vote on an issue
3. Transfer voting rights to another address

This also implies UI work to display active votes, create these tx's, and
so on. I think this feature is a bit further down the roadmap than most of
the other features.

On Mon, Jun 2, 2014 at 6:03 AM, dexX7 notifications@github.com wrote:

Good you mention it, Bitoy. It would indeed help if there were a
transaction which defines the parameters of a vote, e.g. start, end and
topic to vote on. The later raises an interesting question: where is this
stored? I think we should keep the actual data put in the block chain as
low as possible and rather work with external references like a link to a
longer description, if needed, as well as a hash over the content, so it's
visible, if content was changed.

I furthermore realized votes are not necessarily binary -- it's not
always "yes" or "no", but may be a pool of several choices.

Let's boil this down. What's the minimal requirement we'd need? I see it
this way:

1. Some way to define parameters -- the great thing, such a
   transaction is not consensus critical, but rather an additional feature.
   Maybe this can be generalized to "meta data".
2. I suggested to use tokens as representation of votes to lower the
   need for changes. Let's not have a new transaction type for every new
   thing, because ultimately smart properties should be used for general stuff
   and not only as "coins", right?
3. A way to "credit" everyone with tokens or vote rights.

Furthermore up to discuss: Ron's post about the mechanism itself.

—
Reply to this email directly or view it on GitHub
#178 (comment)
.

[dexX7]

I also prefer not to issue "voting tokens", since if buy MSC, I should also
be buying the right to vote on anything which MSC people care about.

Yes, this is of course possible and intended! The idea was to do a 3: Pay Dividends (Send All) to all MSC holders to distribute those "vote tokens".

Security question: what about coins in cold storage?

That's a problem that can't be solved, I think. We could try to issue a tool to prepare offline transactions easier though.

[ripper234]

@dacoinminster we can use the same MSC burning as promoting smart property - everybody can burn more to increase their vote visibility.

Voting on token X should burn token X, not MSC.

[dacoinminster]

EVERYTHING must burn MSC. MWA HA HA HA!

BURN MSC BURN!!!!!

(actually, I'm seriously considering some minor spec changes to require
small amounts of MSC to be burned for any transactions not actually using
MSC)

On Tue, Jun 3, 2014 at 2:11 AM, Ron Gross notifications@github.com wrote:

@dacoinminster https://github.com/dacoinminster we can use the same MSC
burning as promoting smart property - everybody can burn more to increase
their vote visibility.

Voting on token X should burn token X, not MSC.

—
Reply to this email directly or view it on GitHub
#178 (comment).

[ripper234]

I'm against such a change.
On Jun 6, 2014 1:16 AM, "dacoinminster" notifications@github.com wrote:

EVERYTHING must burn MSC. MWA HA HA HA!

BURN MSC BURN!!!!!

(actually, I'm seriously considering some minor spec changes to require
small amounts of MSC to be burned for any transactions not actually using
MSC)

On Tue, Jun 3, 2014 at 2:11 AM, Ron Gross notifications@github.com
wrote:

@dacoinminster https://github.com/dacoinminster we can use the same
MSC
burning as promoting smart property - everybody can burn more to
increase
their vote visibility.

Voting on token X should burn token X, not MSC.

—
Reply to this email directly or view it on GitHub
#178 (comment).

—
Reply to this email directly or view it on GitHub
#178 (comment).

[ProphetX10]

i would recommend an MSC fee if there is a metadex trade between two
metacoins, but not for just sending metacoin from one address to another.

however if that were implemented it does mean a complication in the trading
of those metacoins with msc, if we were to pull off a small amount of the
metacoin to automatically facilitate the purchase and burn of the msc off
the metadex in the case of users who do not have msc in that trading
address.

a way around that would be to create a second market for MSC to those
metacoins, where they are strictly being sold for fees.

the only issue that this brings up is that the fees might get crazy however
that would encourage people to purchase msc off the primary trading market.

I personally am favorable to eliminating free riders for the core features
such as the p2p trading networked escrow that Master Protocol provides.

And this would be a neat implementation of the Tobin Tax except the
beneficiaries are Mastercoin holders as a whole.

http://en.wikipedia.org/wiki/Tobin_tax

[dexX7]

I noticed there were discussions about this feature already in the past. The following is not intended to provide suggestions for an implementation, but rather as general input related to this topic:

I think that above everything else, MasterCoin is an infrastructure with yet unknown capabilities. As one of the first tasks in the MasterCoin protocol, I would like us to implement a way for MasterCoin holders to vote on protocol changes (hardforks).

Before proposing a way to evolve MasterCoin past forking changes, I'd like to explain how MasterCoin can have forks, even though it's not really mined. MasterCoin 1.0 was defined in Willet's original whitepaper ... but Willet is not the master of MasterCoin. If everyone in the world except Willet decides to add feature X to MasterCoin and call that "MasterCoin 1.1", then this will be the de-facto new MasterCoin. The new MasterCoin can contain new operations and transaction types that Willet's original spec does not support, and so the two "worldviews" of MasterCoin 1.0 and MasterCoin 1.1 will diverge - in other words, when we let the MasterCoin 1.0 program parse the Bitcoin blockchain, and also let the new MasterCoin 1.1 program parse the same blockchain, they will disagree on the balance each address contains (1.1 might even contain new types of addresses unrecognizable by 1.0)

With Bitcoin, there is a clear, decentralized way for miners to vote on protocol changes - by hash power. In MasterCoin, there are no miners (well, they're hidden in the Bitcoin layer and are irrelevant to MasterCoin).

I propose the following protocol that MasterCoin can use to control its own evolution:

1. We build one reference implementation of MasterCoin 1.0
2. We now encode the hash of the git commit for the reference implementation of MasterCoin 1.0 in MasterCoin's own code, forming MasterCoin 1.0.1. Everyone starts running MasterCoin 1.0.1.
3. Whenever there is a desire to add a forking change to MasterCoin, anyone can publish a protocol change request into the MasterCoin network using a special message (the message contains a URL of a repository and a git commit hash within that repo).
4. Owners of MSC can vote whether they approve a particular valid fork request (a fork request is valid if its git commit hash is a descendant.of the currently accepted master hash.
5. Once more than 50% of all MSC have voted on a particular fork, it becomes the new standard, and everyone should upgrade to the new client (or else, they will be stuck on the wrong side of the fork).

https://bitcointalk.org/index.php?topic=309729.msg3325143#msg3325143

Ron asked me to spec out what this might look like. If this is acceptable, it could go into the 1.2 version of the spec:

• Mastercoin websites will have a "voting" section for each currency and smart property.
  Owning a currency or property allows you to vote on issues related to how that currency or property should be run.
  • The voting section will list issues which are available to vote on, as well as feature requests, in descending order of popularity, and the current vote tally for each
    Mastercoin messages needed for voting are:
  • Create new issue (title and what the options are, such as YES/NO or A/B/C/D)
  • Vote on issue (address X votes NO on currency Y issue Z)
    Weight of vote is proportional to the amount of currency or property owned by that address (proof of stake)
  • Create a new feature request (title and description)
  • Vote on feature (address X supports feature Z on currency Y) - also weighted by ownership
  • A single address may only support one feature, and may only vote in one direction, however . . .
  • A user may split their vote by using multiple addresses
• When some or all property is transferred out of an address which has voted, the votes of the transferred property are invalidated (this allows the owner of the new address to vote again)
  Votes are advisory votes only, and are enforced by social contract, rather than by the protocol itself

As an example, the Mastercoin foundation will be issuing memberships at some point as a smart property. Owners of those memberships can vote on issues related to the governance of the Mastercoin foundation. Similarly, Mastercoins themselves will have a voting section.

https://bitcointalk.org/index.php?topic=309729.msg3524354#msg3524354

[ripper234]

See also how Qora does voting (Qora, not Quora!)

[ProphetX10]

i would do the voting based on some concept of quorum, otherwise if 50% of
the coins are lost or just owned by lazy people, the protocol will never
change and will likely die due to neglect. though i guess it would
dependent on the by laws of that coin issuance (if such exist), and today
we have the luxury that JR owns enough Mastercoins that along with a couple
others 50% is very easily achieved verbally.

in any case we should take this and gather user feedback from at least 10+
issuers first, as to whether they would want to use this, what is it
missing, what parts are very important, etc. it would in particular be
very useful for shareholder services (though first we need to have the
protocol be able to actual provide issuers of stock equity with a usable
platform).

Thanks,

Dominik Zynis
Skype: dominik.zynis
USA: +1-415-800-4155
dominik.zynis@gmail.com

On Tue, Jul 1, 2014 at 2:18 PM, Ron Gross notifications@github.com wrote:

See also how Qora does voting
https://bitcointalk.org/index.php?topic=522102.msg7534766#msg7534766
(Qora, not Quora!)

—
Reply to this email directly or view it on GitHub
#178 (comment).

[Bitoy]

Here is an alternative way of voting.

From your address with MSC send (Using any wallet) one of the voting dust below to 13gy3KZcuuv3yqrMkx3ucV2qxq6WVLh3Gd

To vote for
Pizza send 0.00006001 btc
Burger send 0.00006002 btc
Pasta send 0.00006003 btc
Buritos send 0.00006004 btc
Philly Cheese steak send 0.00006005 btc

Voted are tallied from the MSC availablity of each address
http://www.mymastercoins.com/voters.aspx
(Those with no TX are manual sample entries )

[ripper234]

That's one possible implementation / workaround.
However I still think we need something integral to the protocol at some point.

[ABISprotocol]

No to Method 2 because it sends people down the path of buying votes.

[dexX7]

@ABISprotocol: part of the original post was intended to start a discussion about this. Do you mind to elaborate why you consider transfering/trading of votes as a bad thing?

[ABISprotocol]

@dexX7 Someone once told me that brevity is the soul of wit. I like to elaborate to make things clear. In this area I've purposefully kept my thoughts short and to the point. As anyone who has read this particular (and in my view, related) thread will understand, my thinking on the matter of "votes" leans heavily in favor of doing away with systems of representation entirely (or permitting them to expire as decentralization proceeds), and where votes exist or are going to be used, I defend the notion of equality (one entity, one vote), rather than the idea of "buying stuff so that someone who is making bank has voice" (and where those who are disenfranchised or not able to participate in a fiscal context, are excluded or diminished). See, in particular, my somewhat detailed thoughts on this sort of thing. I have mixed views on delegation (which has also been mentioned in this thread), but I think it ultimately favors centralization, and I don't like it. I think that be pretty clear. I'll just leave it at that.

[dexX7]

Just some brainstorming and writing down some thoughts.. I believe I found a solution to prevent trading of vote tokens and a solution to restrict the movement of tokens in general, but unfortunally this requires the involvement of a third party and comes with a significant overhead.

---

The basic scheme:

Alice likes to raise a vote and creates a new property called VoteToken. All VoteTokens received by 1AddressYes before timestamp T count as "yes" votes while all VoteTokens received by 1AddressNo before T count as "no" votes. To begin the process Alice sends out VoteTokens to anyone who shall participate in this vote, such as Bob. To be more specific, Alice sends some VoteTokens to Bob's public key hash 1AddressBob.

To cast a vote, Bob can move VoteTokens from 1AddressBob to 1AddressYes or 1AddressNo.

---

The restrictive scheme:

Alice likes to raise a vote which is immune against the trading of vote tokens and creates a new property called RestrictiveVoteTokens. Similar to before all RestrictiveVoteTokens received by 1AddressYes before timestamp T count as "yes" votes while all VoteTokens received by 1AddressNo before T count as "no" votes.

Instead of sending the vote tokens to 1AddressBob, Alice sends the tokens to 3MultisigBobAndAlice - a 2-of-2 multisig script destination which is redeemable, if signed by Alice and Bob.

Alice furthermore creates two transactions: one which spends RestrictiveVoteTokens from 3MultisigBobAndAlice to 1AddressYes and one which spends RestrictiveVoteTokens from 3MultisigBobAndAlice to 1AddressNo. She signs both transactions and hands them over to Bob. Alice won't sign any other transaction or in particular: no transaction with a different destination than 1AddressYes or 1AddressNo.

Since spending tokens from 3MultisigBobAndAlice requires consensus from Bob and Alice, Bob is now limited to 1. do nothing , 2. move the tokens to 1AddressYes and 3. move the tokens to 1AddressNo.

---

The downsides of the restrictive approach are that Alice needs to know Bob's public key (not public key hash) to create the 2-of-2 multisig script which is only available on the blockchain, if Bob spent some coins or tokens before. This is sometimes given, say for example, when Bob participated in a crowdsale, but not always.

Furthermore this requires interaction between Bob and Alice in the forrm that Alice needs to deliever the partially signed transaction to Bob.

[Bitoy]

Another option is to add new property votetoken in tx 50. VoteToken (1 =
yes)

If the tx 50 is a votetoken.

Check if the issuer has sent tokens to the sender. If yes, send tx is valid.
(If not tx is invalid.)

Alice sends votetoken to to Bob.

Bob can

1. send it to a valid 1addressyes or 1addressno. (Valid send because Alice the issuer sent votetokens to Bob)
2. Do nothing (abstain)
3. Send it to Charles. (valid send because Alice sent token to Bob)

Charles tries to send it to 1addressyes. It is invalid because Alice didn't
send tokens to Charles.

[dacoinminster]

I think Bitoy is saying we can skip the multisig step and simply require that the token come from the known address of Bob.

So basically, Charles can't vote, even though he has the token!

[ABISprotocol]

I like this line of thinking as described by @dexX7 in the recent comment on basic vs. restrictive scheme. Again I am not in favor of 'representation,' but the idea of (at minimum) envisioning how one could minimize the straight up selling of voices and votes (perhaps as described within the more restrictive scheme as elaborated further by @dexX7 / @Bitoy / @dacoinminster) is a good running start. Thanks for thoughtfully working on this issue. This seems like a thoughtful precursor to a migration into a form which leans more towards decentralized and distributed participation that is measurable, in lieu of the old standard of merely 'voting,' which comes with its own set of problems.

[Bitoy]

@dacoinminster mastercore can check if the sender of the token came from the list of known address of Alice (address where Alice sent tokens to ).

[dexX7]

Yeah, simply checking, if the tokens were sent from a specific address is of course the easiest way.. but it feels like cheating. :D

That being said, I found a great overview about the usage of tokens in general:
http://letstalkbitcoin.com/forum/post/token-classifications

Now I don't want to drift into OT, but highlight that voting is rather an application on top of the protocol and not a protocol "decision".