Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: BTS Governance voting system design  (Read 662 times)

0 Members and 1 Guest are viewing this topic.

Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
BTS Governance voting system design
« on: November 07, 2014, 03:14:43 PM »


We are working on the designing and implementation of a system enabling BTS owners to vote their shares.  We want to do this as rapidly as possible because being able to do this is a critical prerequisite to any governance development process.  The initial design specs are being collaboratively developed in this publicly editable Google doc:

https://docs.google.com/document/d/1uWpw93xlJk3qwqNAaiwvMeQmXkjUt7e8rco17DOP8UA/edit?usp=sharing


As you can see, we are attempting to address a couple of design issues and need to select the best way to resolve them.

First, how will Canonizer.com verify public Keys (or Titan IDs, will using Titan IDs even be possible?) submitted by Canonizer.com users, to avoid voter fraud?  I hear this issue is already proposed, and in the system, so any detailed information along these lines would be helpful.

Next, canonizer.com currently lists all users in a camp, along with their canonized score (based on the user selected canonizer algorithm) contributing to the total canonized vote for their camp.  Obviously, if we set up a N bitshares N votes canonizer, this canonized support score will publically reveal how many shares each camp supporter has registered and verified with Canonizer.com.  While this may work for some transparent people like Brent Allsop, there is a good chance there are at least a few of you for which this will not be acceptable.  There are many ways this problem can be addressed and we have started brainstorming some of the better ideas in the design document.  We obviously could use a lot more help in this area since we want to pick a design that will do everything everyone wants.

As usual, if anyone can contribute anything to this process, anything would be appreciated.  Brent Allsop is willing to commit some capital towards this development effort.  So if anyone is willing to help with the development in any way, Brent Allsop will be able to pay you for your time in either BitUSD, Bitshares, Bitcoin, Canonizer.com coins, plain old USD, or whatever you would like.

Upwards,

Brent Allsop



Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: BTS Governance voting system design
« Reply #1 on: November 07, 2014, 08:10:26 PM »
Maybe this works as a fast hack for stake polling?

Just say, if you agree with "X" send a transaction to yourself with an amount ending in 5.6243 BTS (or other random small amount).  If you disagree the amount should end in 5.6244.  To vote on issue "Y" send transaction ending in 5.6345 for "yes" or 5.6346 for "no".  The total amount moved is the stake voting (combine inputs).

The balance is validly voting unless any of those shares are subsequently used to vote in the other direction on the same issue and are not counted twice if they vote same direction on same issue.

Then all you need to do is look at the BTS transaction history to add up the votes.

the other thread it polling was recently discussed: https://bitsharestalk.org/index.php?topic=10879.0

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Re: BTS Governance voting system design
« Reply #2 on: November 07, 2014, 08:34:33 PM »
Maybe this works as a fast hack for stake polling?

Just say, if you agree with "X" send a transaction to yourself with an amount ending in 5.6243 BTS (or other random small amount).  If you disagree the amount should end in 5.6244.  To vote on issue "Y" send transaction ending in 5.6345 for "yes" or 5.6346 for "no".  The total amount moved is the stake voting (combine inputs).

The balance is validly voting unless any of those shares are subsequently used to vote in the other direction on the same issue and are not counted twice if they vote same direction on same issue.

Then all you need to do is look at the BTS transaction history to add up the votes.

the other thread it polling was recently discussed: https://bitsharestalk.org/index.php?topic=10879.0

And I can't then take my stake and vote twice?  If the amount of the transfer is is the stake amount, what prevents me from voting and moving my stake and voting again?  Is this case detectable within the blockchain? 

Sorry I still don't understand TITAN ins and outs.  The answer would be obvious to someone who understands this part of the product.
I speak for myself and only myself.

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: BTS Governance voting system design
« Reply #3 on: November 07, 2014, 09:01:10 PM »

And I can't then take my stake and vote twice?  If the amount of the transfer is is the stake amount, what prevents me from voting and moving my stake and voting again?  Is this case detectable within the blockchain? 

Sorry I still don't understand TITAN ins and outs.  The answer would be obvious to someone who understands this part of the product.
You can't vote twice because it is detectable. TITAN doesn't change this.

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: BTS Governance voting system design
« Reply #4 on: November 07, 2014, 10:13:28 PM »
And I can't then take my stake and vote twice?  If the amount of the transfer is is the stake amount, what prevents me from voting and moving my stake and voting again?  Is this case detectable within the blockchain? 

Sorry I still don't understand TITAN ins and outs.  The answer would be obvious to someone who understands this part of the product.
To be clear, even though you can't vote twice for the same issue with same stake, you could use the same stake to vote on 1000s of different issues at the same time and you can change your vote on any issue at any time.  We could even agree on a number that "clears" all prior votes, but really I think there should just be formal polling implemented on chain in the long run.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Re: BTS Governance voting system design
« Reply #5 on: November 07, 2014, 10:58:35 PM »
If this is done, then it should be done right. It should be possible to derive a "messages only" private key for every private key that you control that can be kept online and used to sign cryptographic challenges to allow registering stake on external sites. Proving your stake to an external site should be 100% safe before it starts being put into serious use.

The way to prevent public knowledge about your stake is to allow a user to register any amount of anonymous aliases, and then just spread out their stake among them.

Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
Re: BTS Governance voting system design
« Reply #6 on: November 07, 2014, 11:18:32 PM »
I can see how Agent86's cleaver Idea could be made to work, if that is the majority expert consensus.

Rune, I agree that it would be nice to do this right.  I am not sure if I fully understand what you mean by:   '"messages only" private key for every private key that you control'

I understand that one possibility is to define a standard message format declaring a public key.  Then sign this message containing a particular public key with the associated private key.  Then this signed message could be sent to any voting system, which could then validate the signature.  Are you talking about something like this?  If not, could you provide more details?

« Last Edit: November 07, 2014, 11:20:20 PM by Brent.Allsop »

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: BTS Governance voting system design
« Reply #7 on: November 07, 2014, 11:34:55 PM »
I also think polling doesn't really need to be subject to BM's idea that we can't vote on "more than 101 things."  Because the polls should be non-binding so delegates don't have to do anything to track these polls.  Poll tracking can be done on demand with client.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Re: BTS Governance voting system design
« Reply #8 on: November 07, 2014, 11:49:04 PM »
I can see how Agent86's cleaver Idea could be made to work, if that is the majority expert consensus.

Rune, I agree that it would be nice to do this right.  I am not sure if I fully understand what you mean by:   '"messages only" private key for every private key that you control'

I understand that one possibility is to define a standard message format declaring a public key.  Then sign this message containing a particular public key with the associated private key.  Then this signed message could be sent to any voting system, which could then validate the signature.  Are you talking about something like this?  If not, could you provide more details?

The drawback with the system you mention is that the centralized voting provider can now duplicate your proof and use it to influence voting on other platforms. Registering stake needs to be done with cryptographic challenges (signing a message that the voting platform sends to you with your private keys), but it also needs to be done in a way that doesn't require you to take your cold wallet online just to voice your opinion. I think the best solution is to have 2 private keys, one of them being the real private key, the other being a derived private key that can only be used for signing messages with your stake, but cannot be used to actually send transactions on the network. You could keep the messages-only private key online and ready to vote at any time on. It would not have to be surrendered to the centralized voting platforms, but it would also not be a catastrophe if your computer was compromised.

This will not be trivial to implement into the client, but it will be needed in the long run no matter what. Perhaps the blanket message signed by the real private key can work temporarily until the proper way is ready.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: BTS Governance voting system design
« Reply #9 on: November 07, 2014, 11:51:32 PM »
I also think polling doesn't really need to be subject to BM's idea that we can't vote on "more than 101 things."  Because the polls should be non-binding so delegates don't have to do anything to track these polls.  Poll tracking can be done on demand with client.

The limitation has to do with transaction bloat rather than whether the proposals are binding or not. My proposals on this topic for on-chain proposals involve only 5 additional bytes but have the limitation that delegates must be the ones to submit the proposals to the blockchain (not just any user) and there can only be up to 4 proposals to be voted on at any given time.

However, if we are interested in non-binding proposals without these strict limitations, then in my view they should be done off-chain. Now, whether you want all of the functionality to be within the same BTS client, or you just want the BTS stake signing portion to be in the client and everything else in a separate program, that is a different matter than the voting being "off-chain". The only tricky portion to figure out is how to ensure votes/ballots aren't being censored when these votes/ballots (or at least their hashes) are not all individually being submitted to the blockchain. I think an acceptable solution to the censorship problem would be getting a signature from a notary who is also the entity facilitating the voting functions which claims the ballot was accepted into the pool by the time of a certain block in the BTS chain (I think this is good enough for now until we eventually come up with a more decentralized solution). Doing things off-chain gives us immense flexibility and, if we do it right, still allows us to very accurately and provably poll the consensus of a recent snapshot of the BTS stake with a low likelihood of voter fraud.

Edit: Agent86, I should be more specific regarding what you said about "delegates don't have to do anything to track these polls." Putting the off-chain polling stuff on the actual blockchain can help with the censorship issues I talked about above without increasing the processing burden on delegates (which was one of the concerns bytemaster had with voting on more than 101 things). That is good, but it still doesn't solve the blockchain bloat issue. I suppose if people want to submit a hash of their ballot/vote into the blockchain at their own expense to ensure that it is not censored, then that would be a workable addition to the off-chain voting system I am envisioning, but I would much rather not have the voting system depend on users submitting any information to the blockchain since I want this type of voting and consensus building to be plentiful and extremely cheap.
« Last Edit: November 08, 2014, 12:14:28 AM by arhag »

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: BTS Governance voting system design
« Reply #10 on: November 08, 2014, 04:14:49 AM »
The limitation has to do with transaction bloat rather than whether the proposals are binding or not. My proposals on this topic for on-chain proposals involve only 5 additional bytes but have the limitation that delegates must be the ones to submit the proposals to the blockchain (not just any user) and there can only be up to 4 proposals to be voted on at any given time.
I meant non-binding proposals reduces need for delegate processing/database and I thought this would be the more important issue.  I'm not suggesting increasing max transaction size.  Voting for a ton of things would require paying for multiple transactions.  I'm also not saying you can't enforce reasonable limits.

I don't like limiting proposals to only delegates.  The on-chain solution still seems easier for the user to me.  Is it really much "cheaper" for someone to go to the trouble to manage this off chain?   What do you think of identifiable balances in transactions can be used to poll? I'm proposing to implement polls in an analogous way.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: BTS Governance voting system design
« Reply #11 on: November 08, 2014, 05:02:34 AM »
I meant non-binding proposals reduces need for delegate processing/database and I thought this would be the more important issue.  I'm not suggesting increasing max transaction size.  Voting for a ton of things would require paying for multiple transactions.  I'm also not saying you can't enforce reasonable limits.

Sure, for non-binding proposals, delegates' clients don't need to do any additional work other than validating a somewhat normal spending transaction but with some opaque attached blob of data, and as long as the fee is large enough to justify the size of the blob of data. Then only clients interested in voting functionality can spend the extra processing resources scanning these data blobs to see if they are relevant to the voting functionality and perhaps even further filtering transactions based on whether the blob is about the particular issues the user of the client cares about.

I don't like limiting proposals to only delegates. 

That proposal of mine only applies to binding proposals anyway. It is a consequence of the limitation of only allowing a handful of active proposals at any give time, which is itself a consequence of trying to minimize transaction bloat. Delegates wouldn't need to do anything extra for non-binding proposals, which is what you seem to be mostly interested in anyway.

The on-chain solution still seems easier for the user to me.  Is it really much "cheaper" for someone to go to the trouble to manage this off chain?   What do you think of identifiable balances in transactions can be used to poll? I'm proposing to implement polls in an analogous way.

I really don't like the kludge of using a random number balance to identity a (poll, vote) tuple in a transaction. If the blockchain just has the ability to attach a public blob of data to a transaction (that the spender needs to pay the appropriate fee for) like I mentioned above, you get a lot more flexibility to implement what you are talking about and many other things as well.

Also, a good user interface makes the implementation details irrelevant to the user. So both can be made easy for the user. The only remaining questions are cost, scalability, and decentralization. Putting everything on the blockchain and validating it all with the full clients as they scan the blockchain does mean we get the best of decentralization and it means there are no other third-parties one needs to worry about censoring or manipulating results, however I think that would be costly and unscalable.

I think the better solution is to do most of this off-chain and only utilize the chain for purposes that absolutely require a blockchain, such as publicly timestamping a commitment under one's identity and moving the funds necessary to pay for the expenses of providing the service (ideally through micropayment channels). I mostly would like to do it this way because I want a protocol that can scale to handle services as trivial as upvoting/downvoting a post. Users shouldn't have to validate the votes on every meaningless post (they can trust the reported results by the service providers for the most part), but the protocol should allow anyone interested to collect the necessary data backing the proof of voting results from any sources on the internet and, assuming they can get all this data, they should be able to prove the validity of the voting results regardless of how small or insignificant the poll/election is (again assuming the data backing the proof has not been erased from the internet forever).

« Last Edit: November 08, 2014, 05:11:53 AM by arhag »

Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
Re: BTS Governance voting system design
« Reply #12 on: November 08, 2014, 06:17:47 PM »
What do you guys mean by "non binding"?
Is voting in or out a delegate non binding?  How about voting to dilute to pay for a marketing / recruitment move?...

Agent86, at least some things need to be done off chain, right?  For example who/how are survey question designed, and can they be modified, or improved to achieve more consensus after voting starts?
« Last Edit: November 08, 2014, 10:50:10 PM by Brent.Allsop »

Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
Re: BTS Governance voting system design
« Reply #13 on: November 08, 2014, 11:42:52 PM »
I understand that one possibility is to define a standard message format declaring a public key.  Then sign this message containing a particular public key with the associated private key.  Then this signed message could be sent to any voting system, which could then validate the signature.  Are you talking about something like this?  If not, could you provide more details?

The drawback with the system you mention is that the centralized voting provider can now duplicate your proof and use it to influence voting on other platforms.


This can easily be resolved by having the a server like Canonizer.com provide a randomized UUID, that makes the signed block unique, and not reusable, right?

Brent


Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: BTS Governance voting system design
« Reply #14 on: November 09, 2014, 03:20:07 AM »
What do you guys mean by "non binding"?
Is voting in or out a delegate non binding?  How about voting to dilute to pay for a marketing / recruitment move?...

By "non binding" I just mean that there is no direct consequence of the vote/poll, like an opinion poll.  Voting for delegates or pay rates is binding.

Agent86, at least some things need to be done off chain, right?  For example who/how are survey question designed, and can they be modified, or improved to achieve more consensus after voting starts?
You could register survey questions on the chain.  You wouldn't be able to modify the question/statement retroactively.

 

Google+