Stake weighted voting system (part II) + STO spam

[dexX7]

This is a continuation of #178, which may serve as introduction to the context. I'd like to continue the discussion and introduce a refinement to previous proposals, given the relevance of this topic and it's potential use cases.

http://blog.omni.foundation/2015/02/19/2015-mastercoin-foundation-board-elections/:

To vote for multiple candidates, one will have to split an address into separate, respective addresses. Please note that when voting for a candidate, only the amount of omnis held in an address on 3/20/2015 will be counted, meaning if you vote for a candidate early on, you are able to change your vote by moving the omnis to a new address and sending a dust transaction from there.

While one day these election functions can be programmed, I would imagine that in terms of the software’s priorities at this point in time, this would sadly broach upon scope creep. In the mean time, keep your eyes open for surprises!

As predicted and proposed last year last year, token based voting schemes turned out to be no ficition, but viable, with several votes held by larger players in the ecosystem.

One can think of at least two solutions to do so:

1) Mass distributed vote tokens

New tokens can be created, serving as "vote tokens", and sent to eligible holders of a given currency based on their holdings at a given time. Receivers of such tokens can then cast a vote by sending vote tokens to predefined destinations. It is thinkable that there are multiple destinations, each representing a decision, choice or candidate, or alternatively, multiple vote tokens for each decision are created and collected at a single destination. At the end of a voting period, the number of vote tokens received can be used to determine a voting result.

This is possible for quite a while with any meta protocol that allows the creation and transfer of tokens or smart properties, but it usually comes with two downsides:

1. The initial distribution of vote tokens is based on good will of it's issuer and it's error prone: a fair stake weighted voting system implies holders of a currency or token receive a fair share of vote tokens, proportionally based on their holdings, which requires availability of a correct snapshot of the receiver's holdings at a given time, as well as a correct distribution by the vote token's creator, though there is no mechanism to enforce that an issuer distributes such tokens proportionally, fair, or at all.
2. The initial distribution of vote tokens is usually a manual process, and given current limitations of some meta protocols to bind only one "transfer of tokens" to one "[Bitcoin] transaction", this introduces significant cost, where cost can be measured in terms of transaction fees, it's footprint on the blockchain, or the time and work necessary to create and send all transactions.

One prominent example, unrelated to voting mechanisms, but related to mass distribution of tokens, which comes to mind, is @AdamBLevine's LTBcoin. LTBcoins are distributed weekly, to users based on their activity and participation in the context of Let's Talk Bitcoin. At time of writing, there are 47058 send transactions, of which many can directly be linked to "distribution", as most of them are bind to transactions with transaction fees of 0.0000375 BTC and output values of 0.0000125 BTC, to reduce monetary cost.

It's entirely possible, and common practise, to automate the process of distribution, and one can also reasonably argue that the benefit outweights it's cost, but it is nevertheless clear that this approach likely doesn't scale well and has it's downsides.

2) Protocol based distribution of vote tokens

To reduce cost and to ease the process of (manual) mass distribution, it is thinkable to have a mechanism for vote token distribution on a protocol level, as a "one-to-many" or "multicast" transaction type, where a single [Bitcoin] transaction carries the command to distribute tokens to more than one destination at the same time.

In the context of the Master/Omni protocol such a mechanism already exists in form the Send to Owners transaction type, which can be described as follows:

Transaction type 3 transfers tokens in a specified currency from a sender to the current owners of that currency. The amount to transfer is divided proportionally among the current owners based upon each owner's available balance, excluding the amount owned by the sender.

This almost sounds as a perfect extension to a scheme of using "vote tokens", to resolve both issues mentioned above, as it shifts the trust in correct and fair distribution of tokens from a token distributor onto the protocol layer itself, and it requires only one [Bitcoin] transaction to transfer tokens to an arbitrary number of recipients.

However, there is a notable restriction written in the fine print, which makes the Send to Owners transaction type unusable for mass distribution of newly created vote tokens, summarized as follows:

Send to Owners cannot be used to transfer tokens of a currency to owners of another currency.

This restriction is not arbitrary, but intended as guard against spam. There are several other use-cases of inter-currency multi-sends in addition to a distribution of vote tokens, but unfortunally not far fetched is an (ab-) use of Send to Owners transactions to distribute tokens that receivers may not want to receive. For example, one could use such a mechanism to transfer "advertisement tokens", which could carry a brand name, website link, a statement, ... as part of the token's meta data.

This potential (ab-) use is not limited to Send to Owners transactions, and it was already observable in form of "mass token distributions" more than once, but more generally, spam is not limited to meta protocols, where a closely related example with similar characteristics, to name in this context, is sending "dust" to bitcoin owners, attached with messages that are visible on blockchain.info.

Still, expanding the scope of Send to Owners to transfer tokens to owners of any currency appears to be undesirable, as it may reduce the cost of "spam" significantly, which finally lead to the decision of restricting Send to Owners as in it's current form.

3) Shifting the focus on the root evil of spam

While there are likely other aspects to consider, when evaluating the impact of spam, from an unbiased perspective, spam is not different than any other message, and likewise, Send to Owners transactions of tokens in a specific currency to owners of that same currency is similar to Send to Owners transactions reaching out to owners of a different currency.

The main issue with spam, that I see in this context, is it's annoyance factor, namely confronting users with something that they may not want to receive or be confronted with.

But here is the issue: what might be considered as "spam" by one, could be "valuable" for someone else, and this is entierly based on each user's perception and interpretation, and while I believe certain restrictions to prevent the annoyance of users is perfectly reasonable, it appears to be a problem that should be addressed on a different layer, but not on the protocol level, and this is likely going to be the user interface of an application, more specifically of user clients, wallets and transaction explorers.

---

TL;TR here: a proposal to remove Send to Owners scope restriction

I conclude that the effort of "blocking potential spam" is reasonable, but restricting the scope of Send to Owners to the same currency does not only not solve the underlying issue, but it is also misplaced in my opinion.

Therefore I recommend:

1. Enable inter-currency Send to Owners transactions on the protocol level
2. Hide inter-currency Send to Owners transactions in the default view of applications

Applications should further provide options to show hidden transactions, if an user explicitly wants to do so, but this is not a requirement.

In the context of Omni Core, it could be done by adding a filter for user facing results, while no change to it's core appears to be required, and should neither be changed at all, since consensus, in contrast to the user's view, must be the same for all users. Removing the restriction of STO is consensus affecting though. Assuming Omni Core is used as backend by the primary applications, namely Omni Wallet and Omni Chest, then the impact of such a change would probably be limited.

In the long term it seems unavoidable to deal with unwanted tokens, whether the source is a STO transaction, sent manually, or whatever else.

Please evaluate this with a focus on the concept, instead complexity.

[AdamBLevine]

The problem with voting using tokens is you can sell your vote. Is that acceptable in your system? If it's not, you should be creating a registration process that associates voters with public keys which perform the same verifiable purpose without the issue of now preventing people who shouldnt be able to vote from doing so.

Unless vote-buying is not something you are concerned about it's a pretty intractable problem using the blockchain because that auditability also means you can easily sell your vote. The reason we have anonymous voting with no reciept is because it makes it impossible to sell your vote without the vote buyer having to trust that the vote seller isn't lying to them and taking the pay for their vote even while working against.

If you don't mind vote-buying, I think there are some subtle modifications that could be made to a new blockchain to add retractable coins specifically designed for this purpose rather than trying to broadly repurpose tokens on an existing metalayer.

i've written about it in the past here https://letstalkbitcoin.com/blog/post/http-labshumintis-politik-

[dexX7]

I think there are some subtle modifications that could be made to a new blockchain to add retractable coins, ... https://letstalkbitcoin.com/blog/post/http-labshumintis-politik-

Good read, and interesting idea.

The problem with voting using tokens is you can sell your vote. Is that acceptable in your system?

It really depends on the context and goal, and there are several scenarios where it might be acceptable, and likewise, where it should not be possible, but this seems to be a "higher level" issue, similar to whether voting actions should be obscured, associated with identity of some kind, ... how voting results might be handled is yet another topic.

Rules, boundaries and behavior can be enforced or incentivised, to some degree, where a "tiks-panic-vote-callback" mechanism is a great example. It's also thinkable to use multi-signature schemes (#178 (comment), ...), or other script based mechanisms. Depending on the requirements and context, it might also be sufficient to establish a social contract in form of: "You and I agree upon, that ..."

Let me say it this way: my intention with this issue is not necessarily to push adoption of token based voting, but to remove constraints of Send to Owners transactions, which could then be used to facilitate token based voting schemes.

[zathras-crypto]

I haven't had the chance to read the material pertaining to this discussion, however just to apply the most simplistic principle here - given the rules of a protocol can be set based on requirements, is it not feasible to simply employ a type of voting token that can be distributed in a STO model transaction, but which are simply not transferrable (ie any send other to than an open vote is considered invalid).

Just thinking out loud here.

Thanks
Z

P.S. People really need to stop using the word 'currency' to describe tokens :P The spec does it everywhere but it has been ack'd numerous times that it's not always the case that a token = currency