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

0 Members and 1 Guest are viewing this topic.

Offline Agent86

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

Offline Brent.Allsop

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

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