Hi Xeroc,

Again, thanks for all your brilliant help with this and everything!!

I am using wallet_account_list_public_keys.
It lists 6 different versions of each public key, right?
You said: "you can get the balance ids and addresses", I didn't know these were different.  What is the difference, and which one is which, in what wallet_account_list_public_keys provides?

Also roadkill is asking for "something like wallet_sign_bal_hash", which seems to me to be wrong in multiple ways.  Number one, you don't want the balance included, as you want thin wallets to be able to perform the validate public keys operation, without needing the blockchain.  The balance query need not be verified, only the validation of the public keys.  So a voting system must make a single validation query, to a thin wallet, and repeated balance queries, when needed, using validated public keys, in the open, to any client with a block chain, right?

Second, you don't want a specific signing mechanism, do you?  You just need an ability to sign any arbitrary hash.  And the hash must be of a data set that includes not only the public key, but also include a random UUID generated by the voting system so that people can't re-use the signed block, fraudulently, as other people have pointed out is a problem, right?  Isn't there already a generic sign any old hash function out there?  That is all you need, right?

And I am interested in first things first.  For the first version proof of concept prototype, I am thinking you can get by with people submitting non verified public keys, which we can query balances on in real time, every time we canonize things.  Then, once we get that running, we can move on to validating people's keys.


It seems to me this validation of keys process needs a way to enable a voting system, like Canonizer.com, to contact a users wallet (thin or thick), for this validation process to be easy.  Would everyone agree?  What is the best way to do this?  Can you make an RPC or even an http call to a person's thin wallet from a system like Canonizer.com?  If so, how would that be done?


I still think blockchain_get_balance is broken (can anyone get this to work, recently?), but you are right, I will move this to the technical support thread.

Brent

Notice that calculating the voting power in control of each user requires solving a linear system where the number of rows is equal to the number of users (or more accurately the number of vertices in the delegation graph). This cannot be solved during a HTTP GET request.

OK, now I fully understand.  Thanks for your patience.  As I indicated, this kind of delegation is already exactly, what is being done at Canonizer.com, we just don’t use all that complicated stuff to describe it and simply build a tree where the root is the survey topic, and there is a tree of supporting camps.  Each camp has a list of “direct supporters”, each of who can have a tree of people delegated to them.  We do a depth first traversal of the tree, totaling up (and displaying) the value at each node.  The values you see displayed at each node, is the sum of everything below it in the tree.  So all that linier equation and eigenvector stuf was just confusing me.

There isn’t yet a lot of delegation going at Canonizer.com, but here is an example of one camp that has one person (Sphire000) who has delegate their vote to me.

http://canonizer.com/topic.asp/88/36

At canonizer.com, if you support more than one camp, your total canonized score is cut in half for the top supported camp, and half again of that for each additional camp and so on after that.  That is why the two of us each have one vote in that camp, since that is my top camp and we support other camps in that survey topic.

Of course, the default Canonizer algorithm is one person one vote, so quite simple.  The “Expert consensus” Canonizer algorithm is much more complex, and triples the amount of canonization calculation that needs to be done (see: the info about this expert Canonizer here:  http://canonizer.com/topic.asp/53/11 ).

But we currentlyu do all of this in real time, so you can see how fast this works, at least for the 50 or so participators do date.  I”ve always known this exponential algorithm will not scale well, and that someday we would need to do the kind of cashing of pre calculated scores, as you describe, but that is fairly simple enhancement, once you get to that point.

So, all we need is a canonizer function that, given a person (with registered public keys) produce the number of shares they own.  So everything is already almost done and working.

When people register their shares, I’m currently planning on letting them specify a privacy score.  This score will be the number of people required, before the number of shares are displayed at any node.  I’m thinking of having a default of 10 people.  In other words, only if you have 10 people delegating their score for you, will it show how many shares you are voting, since nobody will know how many of those shares are yours vs your 10 delegates.

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?

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

Hi arhag

It looks like great minds think alike.  Most of this, especially the infinite delegation stuff, is identical to what canonizer.com already does, or is planned, except for a few minor details.  And there are some things you are talking about that I don’t understand yet.

I am not quite sure why you would want to slow things down, and do not know what the eigenvalue problem is, nore why you would need multiple snapshots of the data.

Perhaps you could be a bit more specific about design details, and include them in the collaborative design document we are working on.  In other words, maybe more like pseudo code level specifications.

https://docs.google.com/document/d/1uWpw93xlJk3qwqNAaiwvMeQmXkjUt7e8rco17DOP8UA/edit

@Brent.Allsop:  Please explain the Registration form. Why is "Legal Middle Name" the only required field, and not, say, "Nickname"?

I have fixed this issue by updating the descriptive text, so would be interested in feedback regarding if my fix is adequate.

Thanks for the feedback.

I have created a wikiable google doc to facilitate the collaborative specification of exactly what should be done for this, and how to get it done, starting with the original specifications by toast.

https://docs.google.com/document/d/1uWpw93xlJk3qwqNAaiwvMeQmXkjUt7e8rco17DOP8UA/edit

I have some capital I am willing to commit to this project to pay or reward people for contributions.  I can pay in either BitUSD, BTS, Bitcoin, Canonizer.com shares, or whatever people would like.  So if anyone knows of anyone that might be able to help with this, please point them in our direction.

We specifically need help with the design and implementation of the Blockchain process that can collect the verified Bitshare ownership data, in a way that can be verified by anyone at any time.  If anyone is more familiar with this process and could help get me up to speed, please contact me.

And if people could periodically bump this thread, so more people will be aware of what we are doing, that would be a big help.

In my opinion, we need more than a simple voting system, we need to be able to build consensus.

For example, let us say the entire community is in the camp that we should not dilute.  Let us say that some expert, like The bytemaster, or whoever, is the first person to realize we should dilute by X amount to accomplish Y.  Of course, if you do the vote at that moment, The bytemaster will be the only one that even knows about this new idea.

The issue then becomes, we need a tool we can all use, so that it is very easy and efficient for leaders like The bytemaster to get the entire heard educated and on board.  You need to measure how many people get on board, for what reasons, and how many people are not YET on board.  The system has to be able to know, concisely and quantitatively what is holding everyone else up.  The focus needs to be on negotiating things until you can make everyone happy.  And you can not hope to make everyone, or at least the most people possible, happy, if nobody knows, concisely and quantitatively, what that is.

The problem with traditional voting system or petitions to sign, is they can’t change to build consensus, so they tend to destroy consensus and polarize people.  Once the first person checks a box, or signs a petition, nothing can change – and THAT is the problem.  David Chalmers did a now infamous traditional survey of philosophers of mind.  He decided the possible choices everyone could check, and then asked everyone to take the survey.  People spent forever saying things like when person X voted for Y, they really meant Z, and stuff like that.  It just added to everyone’s miss perception that there was no consensus in this field.

Yet, when the consensus building system at Canonizer.com was employed, to date everyone has achieved a 75% popular consensus for the “Representational Qualia Camp” http://canonizer.com/topic.asp/88/6 and a near unanimous expert consensus for this camp.  The only disagreements are the much less important things represented concisely and quantitatively, in the sub camps.  And as I pointed out in the initial constitution thread, the philosophy of mind crowd is a far more diverse crowd than the Bitshares community.