Author Topic: BTS Governance voting system design  (Read 4040 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Brent, "non binding" just means that the blockchain will not automatically change based on a proposal getting approved by enough stakeholders. It is still useful in letting everyone understand and come to a consensus on what the stakeholders want (or perhaps what the majority of the stakeholders want). This is useful even if the proposal is "non binding" because it, for example, allows the delegates to safely hard fork to a client that implements the features approved in the non-binding proposal without worrying about pissing off the majority of stakeholders and getting voted out.

I would still personally like to have some binding proposals designed into the system as well so that we can dynamically change the rules of the blockchain in certain specific ways without requiring everyone to download a new client. Some examples of dynamically changing the rules of the blockchain without requiring a new client could be changing the minimum collateral ratio for shorting BitAssets, or adjusting the dilution rate cap, or adjusting a cap on the yield rate for BitAssets. But the vast majority of proposals that are still useful in allowing the stakeholders to come to a consensus on the future direction of BitShares could be "non binding" without any problems.
« Last Edit: November 10, 2014, 07:20:18 pm by arhag »

Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
Hi Agent86,

I guess we are talking two very different things, then.  The primary use case I am pushing towards is how can the experts (i.e. the Bytemaster and others) get the entire dumb herd do something like allow something like dilution to support a marketing push, while losing the fewest possible sheep.  You need to be able to rapidly educate (and get intelligent expert feedback from) the entire herd, and it is also critically important that you be able to measure how effective your communication is, what works, what doesn't, how many people are not yet on board, why (real time, concisely and quantitatively for millions of  people), and what would be required to get them on board.  It all needs to be very flexible, constantly being negotiated and changing, so everyone has visibility into the current state of the consensus (both expert and popular)  All this stuff needs to be much more than just meaningless 'non binding' stuff, so there is certainty and trust.  it is not good for everyone to sell everything when there is so much uncertainly while we work at building consensus, and guessing at how much we may or may not have.

It sounds like the 'non binding' stuff you guys are talking about is very different than this, and really has nothing to do with governance or a "constitution" or anything, which is the topic of this thread?

Brent

« Last Edit: November 10, 2014, 06:33:51 pm by Brent.Allsop »

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
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.

Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
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 Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
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 arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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 Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
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: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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 Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
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 Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
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 Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
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 Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
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 Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
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 Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile

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 gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
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.