Author Topic: BTS Governance step 1: Basic stake polling  (Read 10010 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I am using wallet_account_list_public_keys.
It lists 6 different versions of each public key, right?
Yes .. same information .. different format. You will also find a corresponding
PTS and BTC address .. for that particular key. if you dump the private key for
that particular key (haven't tested) you should be able to import it in electrum
and redeem and btc/pts

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?
Oh, seems like balance_ids are the same as addresses :)
For me a balance id is a "unspent output" .. but those do not really exist in
BTS so you are right .. balance_ids == addresses :)

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?
with wallet_sign_bal_hash you could sign with the key for the balance_id/address
.. thus, the signed message identifies an address for which you can (onchain)
figure out how much stake the signer has.

example:
- I own balance ID BTSXFooBar
- I sign the text "This is xeroc, and I vote for candidate A with my 100 BTS
  stake" .. signing (the hash of the message) with the key for BTSXFooBar and
  append it to the text
- everyone can now identify my balance address BTSXFooBar and check ONCHAIN, if
  I really have 100 BTS in that address .. if so .. the vote counts (more
  precisouly, the vote counts with the weight of all BTS in the address)
thus you can vote with your stake without moving it, but the checker has to have
a recent copy of the blockchain to verify the "weight".

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?
you can sign ANY data that is as long as a SHA256 hash .. i.e. 256 bit. no
matter where it comes from. But to be able to verify the signature you might be
required to also publish the signing address/balance_id .. otherwise you might
need to bruteforce verify all existing balance_ids.
The same happens when you sign sth. with a BTC address. The format goes
something like this:

Code: [Select]
---------------
Text
---------------
address to sign
signature of hash(Text) with the address above!

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?
Seems reasonable to me

Quote
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.
can't check right now .. I am compiling :)

Offline roadscape

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?

Such a method would sign a message to verify ownership of the private keys of balance_ids. The balance itself should not be included... it would be redundant.

Second, you don't want a specific signing mechanism, do you?  You just need an ability to sign any arbitrary hash. 

A "specific" mechanism allows us to not deal with the private keys directly, which is a good thing IMO.

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.

This is possible and trivial. But the minute someone gets the genius idea to simply vote with all the balance_ids in the blockchain, the fun is over.

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.

I've had good luck with just 'get_balance'.
http://cryptofresh.com  |  witness: roadscape

Offline Brent.Allsop

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

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


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Aha, thanks! I didn't realize the hash had to be in quotes.
But this doesn't involve balance_ids, I don't think it will work for authenticating stake.

I believe I need something like this:

wallet_sign_bal_hash <balance_id> <hash>

Does such a thing exist?
I am afraid we don't have a CALL for that yet .. the example above indeed uses the account key and nothing else :(
I missed that point :-\

Isn't this console command what you / we are asking for?:

blockchain_get_balance <owner_address>
You can get the balance ids and addresess .. but there is no call to sign a message with the private keys to THOSE addresses! there is just a command to sign with the account owner key

Quote
Now if I could just get this guy to work.  Can someone provide me an example of a random owner_address of some Bitshares on the blockchain?  I've been trying to use some of what I think are mine, but can't seem to get anything to work.  All I seem to get is an assert exception with no details about what caused the exception?
Hug? maybe you open up another thread to fix this issue.

try command wallet_account_list_public_keys

Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
Aha, thanks! I didn't realize the hash had to be in quotes.
But this doesn't involve balance_ids, I don't think it will work for authenticating stake.

I believe I need something like this:

wallet_sign_bal_hash <balance_id> <hash>

Does such a thing exist?
I am afraid we don't have a CALL for that yet .. the example above indeed uses the account key and nothing else :(
I missed that point :-\

Isn't this console command what you / we are asking for?:

blockchain_get_balance <owner_address>

Now if I could just get this guy to work.  Can someone provide me an example of a random owner_address of some Bitshares on the blockchain?  I've been trying to use some of what I think are mine, but can't seem to get anything to work.  All I seem to get is an assert exception with no details about what caused the exception?

Brent







« Last Edit: November 10, 2014, 03:58:52 am by Brent.Allsop »

Offline Brent.Allsop

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

« Last Edit: November 10, 2014, 02:25:24 am by Brent.Allsop »

Offline roadscape

wallet_sign_bal_hash <balance_id> <hash>
I am afraid we don't have a CALL for that yet .. the example above indeed uses the account key and nothing else :(
I missed that point :-\

Certainly not too late to toss it into v4.24 :D

I've posted a feature request on GitHub.
http://cryptofresh.com  |  witness: roadscape

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Aha, thanks! I didn't realize the hash had to be in quotes.
But this doesn't involve balance_ids, I don't think it will work for authenticating stake.

I believe I need something like this:

wallet_sign_bal_hash <balance_id> <hash>

Does such a thing exist?
I am afraid we don't have a CALL for that yet .. the example above indeed uses the account key and nothing else :(
I missed that point :-\

Offline roadscape

Code: [Select]
(wallet closed) >>> help wallet_sign_hash
Usage:
wallet_sign_hash <signing_account> <hash>                                                             Signs the provided message digest with the account key
Signs the provided message digest with the account key

Parameters:
  signing_account (string, required): Name of the account to sign the message with
  hash (sha256, required): SHA256 digest of the message to sign

Returns:
  compact_signature

where "hash" is hash(TEXT)

Aha, thanks! I didn't realize the hash had to be in quotes.
But this doesn't involve balance_ids, I don't think it will work for authenticating stake.

I believe I need something like this:

wallet_sign_bal_hash <balance_id> <hash>

Does such a thing exist?
http://cryptofresh.com  |  witness: roadscape

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Is it possible to sign an address-message using RPC? That's what I'm stumbling on.

Code: [Select]
(wallet closed) >>> help wallet_sign_hash
Usage:
wallet_sign_hash <signing_account> <hash>                                                             Signs the provided message digest with the account key
Signs the provided message digest with the account key

Parameters:
  signing_account (string, required): Name of the account to sign the message with
  hash (sha256, required): SHA256 digest of the message to sign

Returns:
  compact_signature

where "hash" is hash(TEXT)

Offline roadscape

d) Use linkable ring signatures (see CryptoNote for example) to dissociate your voting power from the stake on the blockchain and thus get both privacy and full representation.

[..]

This is all new to me, and I appreciate your insight. Thanks!

Ignore privacy for now, large stakeholders are going to be known anyway. You can mix your stake between sessions if you want.

We have a way to get all account balances, and to request and verify signed messages for a particular address. We just need to do the stuff described in this thread, it's a two day task for a dev who can focus.

I agree about ignoring the privacy for now. I wasn't trying to say it's a problem; rather, I just wanted feedback on if I'm building a correct understanding of the system and its caveats.

Is it possible to sign an address-message using RPC? That's what I'm stumbling on.


I still think this functionality is worth doing "on chain."

Agreed, though I do think it's worth it to create a working proof of concept.
« Last Edit: November 05, 2014, 06:23:15 pm by roadkill »
http://cryptofresh.com  |  witness: roadscape

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
I still think this functionality is worth doing "on chain."  I also suspect you will get less participation if it is not built into the client.  I think people should be able to register a statement/poll and people can vote it up or down.  I also think we put too much effort in worrying if everything is untraceable.  You could limit the amount of time polls stay active or limit the number of active polls in other ways.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Ignore privacy for now, large stakeholders are going to be known anyway. You can mix your stake between sessions if you want.

We have a way to get all account balances, and to request and verify signed messages for a particular address. We just need to do the stuff described in this thread, it's a two day task for a dev who can focus.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Unless I'm mistaken, it is impossible to privately vote without splitting your stake.
Because a stake can only be in one place at one time.

This creates an incentive for the privacy-minded to either:
a) not vote (giving them no representation)
b) split their stake (giving them less representation)
c) give up privacy (the corollary being that the demoracy-minded have an incentive to be responsible/transparent)

d) Use linkable ring signatures (see CryptoNote for example) to dissociate your voting power from the stake on the blockchain and thus get both privacy and full representation.

That would create a pseudonym with which you can vote with that is not linked to your BTS account (nor linked to the transactions on the blockchain from which you pay people and thus reveal your BTS account, and perhaps real identity, to them by doing so). If you are instead concerned about not connecting voting patterns to one pseudonym (for example we see that the person who voted Dan for question A also voted No on question B), then you would need to have each issue/election require a set of pseudonyms allocated entirely for voting on that issue/election. So I would have two linkable ring signatures on my BTS stake (say it's 100 BTS) that are not connected to one another because they use a different hash (say the hash of the issue/election) and I devote all of that stake to the two different pseudonymous accounts (account A and account B). So, account A would have 100 BTS devoted that can only be used for issue A while it has 0 BTS devoted to that account that can only be used for issue B (because otherwise it would link account A to account B, and also be invalid since it is already devoted to account B). And, account B would have 100 BTS devoted that can only be used for issue B while it has 0 BTS devoted to that account that can only be used for issue A (because otherwise it would again link account B to account A, and also be invalid since it is already devoted to account A).

Trying to maintain privacy with this voting system does makes things complicated but I believe it should be possible.
« Last Edit: November 05, 2014, 04:30:56 am by arhag »

Offline roadscape

I'm exploring the privacy aspect.. Turns out it's a bit of a challenge and there are trade-offs:
http://wiki.bitshares.org/index.php/DPOS/ApprovalVoting#You_choices_for_transactions

Say I set up a transparent voting site with several polls.
Ballots are cast by submitting (à la delegate) your signed (key, vote) pairs.
A. Who is better: Dan or Stan
B. Are you on welfare: Yes or No

Unless I'm mistaken, it is impossible to privately vote without splitting your stake.
Because a stake can only be in one place at one time.

This creates an incentive for the privacy-minded to either:
a) not vote (giving them no representation)
b) split their stake (giving them less representation)
c) give up privacy (the corollary being that the demoracy-minded have an incentive to be responsible/transparent)

Sounds a lot like the uncertainly principle:
Quote
In 1927, Werner "Roadkill" Heisenberg stated that the more precisely the outcome of a shareholder poll is determined, the
less privacy its members have, and vice versa.
http://cryptofresh.com  |  witness: roadscape

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Oh, that delay stuff is all for anonymity purposes, now I'm catching up with you.

Actually the delay / snapshot stuff is not about anonymity. It is because I suspect properly calculating the voting power in control of the different users will take some time to do. Given a snapshot of the BTS stake devoted to a user and the delegation graph between users, it will take some time to compute how much voting power each user should have. In particular it is the delegation aspect that adds computational complexity (solving a linear system). See this blog post for some details.

The rows of that adjacency matrix correspond to how a particular user delegates their voting power to other users. The sum of the values in any given row in the matrix should be less than or equal to one. If it is less than one, then the difference is meant to be sent back to the user that the row corresponds to (remember there can be no cycles in the graph). Refering to the blog, the 1s as the last terms of the left hand side of the linear system represent the initial voting weight given to each user before delegation. In this case they each have the same weight, but in our case the weight would be determined by the BTS stake devoted to each user. Anyway solving for the voting power of each user requires solving a linear system where the number of rows is the number of users (also, I don't get why that blog calls it an eigenproblem when it is actually not because of the column of 1s).

So using the first example problem in that blog, the first step of the solution is to solve the linear system which gives A = 1, B = 2, C = 3 since A delegated its entire vote to B who delegated its entire vote to C who didn't delegate the vote to anyone else. But to conserve the total voting power, we then need to calculate the voting power controlled by each user after this delegation process. This means the difference between 1 and the sum of the values in each row of the adjacency matrix needs to be used to determine how much of the linear system solutions is actually in control of each user. So the final answer to how much voting power each user should have is given here.

Let's take a more complicated example. Say Alice, Bob, Charlie, and Dan are users in the system. Alice and Bob both have 1000 BTS devoted to their account. Charlie has 0 BTS devoted to his account. And Dan has 10,000 BTS devoted to his account. Alice decides to give 50% of her voting power to Bob because she trusts him but also wants to maintain the other half of her voting power for herself. Bob decides to give up all of his voting power split equally between Charlie and Dan because he thinks they are best suited to make decisions on his behalf and he doesn't want to spend time thinking through various proposals or camps. Charlie chooses to keep all of his voting power to himself. Dan chooses to give Charlie 10% of his voting power but keeps the other 90% to himself. Assuming we order things in alphabetical order, the adjacency matrix now looks like this, the solution to the linear system is this, and the voting power in control of each person at the end of this delegation process is this.

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. In fact, it could take considerable time to solve as the number of users gets big. For this reason, I think this should be done in the background asynchronously with the most recent snapshot (snapshot of the latest devoted BTS stake and delegation graph). Once it is done, it should run again immediately afterwards using the most recent snapshot. This way there are computers in the background constantly solving linear systems (as long as there have been changes to the devotion or delegation graph of course) computing the most recent state of voting power for each user. In the mean time, another set of computers can use the most recently computed voting power in control of users and the way they have voted on issues (or the camps they have joined) to calculate the aggregate voting power in support of a certain issue or camp. These cached results are what the website will refer to when providing the website browsers the numerical voting results on issues/camps in response to HTTP GET requests.


I will try to find the time to write about the details of my voting system proposals more formally in a separate document. Then people can look through it, ask for clarification, correct things, make suggestions, and then eventually you can merge those as desired into your own documents.

« Last Edit: November 04, 2014, 04:00:18 am by arhag »

Offline Brent.Allsop

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

Hi arhag

Oh, that delay stuff is all for anonymity purposes, now I'm catching up with you.

I am going to continue to work on better understanding exactly what you are talking about, with the goal of adding some  psuedo code to the wiki Google design document mentioned:

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

You could probably add specific pseudo code better and faster than I, so please you, or anyone, feel free to help me specify exactly what we need to do for this.



Offline Brent.Allsop

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

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

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
arhag, what would it take to get you to work full time for BitShares?

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Great, so are you going to take the initiative and add a "One BTS One Vote" algorithm into the list of Canonizer algorithms as well as the tools necessary to verify the signatures to allow users to prove stake ownership?

Absolutely.  It would definitely be possible to get this to do everything being proposed, and I will do everything in my power to code this and make it happen.


I must warn everyone that I have a full time job, and have other commitments, so the amount of time I can commit to this is limited.  If others could step up and help with this, we could get it up and running much faster.  There is quite a large list of things that need to be done to get this functional.

I have other commitments as well but I am happy to freely discuss and iterate on the foundation and architectural design of the system I would like to see created. I discuss some of this architecture in this post. The end product of all of this beyond the website itself would be to develop the minimum open source software needed that can communicate with a trusted client using the RPC interface, as well as changes to the client itself, to facilitate any website to create a voting/governance system based on one bts = one vote. The architecture and specifications would also be designed so that the website could optionally provide all the necessary cryptographically-signed proof that it logs to the public so that they can use their client and these open source tools to verify the accumulated votes for any specific issue/topic/camp. I would also support a few delegates to fund the development of these open source tools and the necessary changes to the client (no hard fork changes needed).


Currently, we do the canonization process in real time, every time someone loads the page.  I'd think we should be able to have a cashed snapshot of the block chain share ownership being constantly updated, and continue doing this in real time.

Yes, I don't think it should (can?) be done in real time. Here is how I view things happening on the servers of a site like Canonizer that is modified to support this type of BTS voting. The databases on the servers would regularly take certain snapshots of data as it is either updated in real time or computed from a prior snapshot. There would be five classes of snapshots:
  • BTS stake devoted to each user on the website.
  • Delegation of voting power of users on the website to each other.
  • Voting decision by each user on the website for each issue (or camp) on the website.
  • BTS voting power controlled by each user on the website.
  • The accumulated BTS votes for each issue (or camp) on the website.

The website would have a client running on the servers to gain read-only access to the BTS blockchain/database. People can register users on the website and associate a public key to that user (they locally generate and safely store the private key). Users can optionally associate themselves to a BTS TITAN name if they wish. To do so they need to mutually link the accounts by signing a statement of the link by both the Account key on the blockchain (requires BTS client support) and the private key meant for the user on the website.

Users can at any time update the devotion to their user. Doing so requires signatures from keys that are allowed to vote for (currently that also includes the ability to spend) the unspent BTS balances sitting on the blockchain. This also requires BTS client support. I imagine a simplified process where a link (bts URI scheme) on the website launches the client with a request to update devotion to a user. The client then prompts the user to select all TITAN accounts whose current BTS balances they want to devote to the website user. The user makes the selection and presses the OK button which causes the client to make all the necessary signatures and then feed this data to the website using a HTTPS GET request. The website then gets this data, verifies the signatures are good using its RPC access to the blockchain/database (the data should follow some standard specification and the actual verification should be done by the common open source tools), and updates the BTS balances devoted to the particular website user. The website also needs to use its access to the client to get notified whenever an unspent BTS balance that was used to devote to a user is spent on the blockchain (this requires changes to the client and new RPC APIs). The website can then update the BTS balances devoted to a particular website user if some previously devoted stake now becomes invalid since it was spent to another address. All of these updates to the current devoted stake for each website user is happening in real time.

What is also happening in real time are the changes by the website users in how they delegate their voting power and how they vote on the various issues or which camps they support. Users can split their voting power as they wish to any number of other users on the website. This forms a graph where the vertices are the users and the directed edges are the delegation of voting power. It is important to avoid cycles in this graph (so it should be DAG, directed acyclic graph). Thus the request to change a user's delegation of voting power is submitted to the server, but the change doesn't actually occur in the database until the website confirms it is valid (it does not create cycles). The servers check for cycles and if they exist the update is cancelled and the user is provided with an appropriate error message explaining the issue. The user's request to change the issues they vote for or camps they support should quickly succeed without failure on the other hand. In both cases, the requests need to be timestamped and signed using the user's website private key (this is important to allow later validation by anyone).

Every once in a while the server will take a snapshot of the existing databases storing the information about the current BTS balances devoted to each user and the current delegation structure between users. This would be a class 1 and 2 snapshot. At the same time, the server would also take a snapshot of the database storing the voting decisions of each user, which would be a class 3 snapshot. The server can then proceed to calculate the BTS voting power controlled by each user and then the accumulate BTS votes for each issue.

After the class 1 and 2 snapshot, the server can use this information from the snapshot to construct the adjacency matrix for the eigenvalue problem that solves for the BTS voting power controlled by each user. The server can then proceed to solve that eigenvalue problem. All of this is happening in parallel to the normal operation of the server including the updates being made to the BTS stake devoted to each user and the delegation of voting power between users (hence the need for the class 1 and 2 snapshots). Once the eigenvalue problem has been solved, the server then caches those results (class 4 snapshot), and uses them along with the class 3 snapshot to calculate the accumulated BTS votes on each issue (which it also then caches with the class 5 snapshot). The server can then repeat this process again with a new class 1 and 2 snapshot of the current state.

While the previous process is occurring, the server can also provide a less accurate but more recent update to the accumulated BTS votes on each issue. Say the class 1 and 2 snapshots occurred at time t1. A class 3 snapshot also occurred at time t1. These snapshots eventually lead to the class 4 snapshot for the data taken at time t1 and then quickly thereafter a class 5 snapshot for the data taken at time t1. Once that is done, the server can then take a new class 1, 2, and 3 snapshot at time t2 and repeat the process. However, while the server is computing this information (the eigenvalue problem can take some time) it can make use of the class 4 snapshot for the data taken at time t1 along with a more recent class 3 snapshot to get an estimate of what the class 5 snapshot will be. The server can first use the class 3 snapshot at time t2 and the class 4 snapshot for the data taken at time t1 to calculate an estimated class 5 snapshot for the data taken partly at time t1 and partly at time t2. Once that is done, the server can then repeat this process using a new class 3 snapshot taken at time t3. This will generate an estimated class 5 snapshot for the data taken partly at time t1 and partly at time t3. You can imagine this can repeat for a while (say until time t5) before the eigenvalue problem has been solved and a new class 4 snapshot for data taken at time t2 is available. The server would then calculate a class 5 snapshot for data taken at time t2, but then it would also calculate an estimated class 5 snapshot for data partly taken at time t2 and partly taken at time t6. The server would then also take a new class 1 and 2 snapshot at time t6 to repeat the eigenvalue problem.

I imagine the previous paragraph was pretty confusing and I should try to better clarify it later. But the point is that the server can do many things in parallel, and at any given time it has two types of the most recent voting results for each issue. One type is the very accurate but older one which are the accurate results as determined if someone were to take a snapshot of the blockchain at a certain time as well as a snapshot of the delegation and voting decisions of the website users at the same time, and then determine the consensus from that data. All the information for calculating this should be stored by the server so that it can be provided to users who can then use it to prove the validity of the consensus reached. The other type is an estimate of the consensus that will eventually be properly calculated in the next complete snapshot. While less accurate (since the voting power in control of each user may have changed but not yet reflected in their voting consensus) it is also more recent. I think the website should show the recent results of both types next to the issues/camps they refer to, along with the snapshot dates that the calculations were using.


True, the text and structures of the camps, and such, would be centrally controlled and run on a server, but anyone would be able to validate any of the votes for these camps with appropriate tools, any time.  And that is the only thing that really needs to be on the block chain, at least to get started.  And my understanding is that the "vote" stuff being developed already does what we need.

So with the system I described as long as the website stored and makes available on request the signed BTS balances devoting to particular users for all valid unspent BTS balances at the time of the snapshot, and the users' most recent (up to the limit of the snapshot date) signed requests for updates to their delegation and voting decisions, then all of that information along with the information accessible from the blockchain would be enough for users to independently verify the voting results on any issue (or the amount of support behind any camp). Obviously there would need to be some standard specification for all of this and an open source client that users can run to do all the necessary calculations using the provided data to derive the consensus results.

Also in my view the voting decisions by the users would follow the standard specification of voting with approval on a particular unique issue represented by a hash. Different websites could use this fundamental construct to represent different things. For example the hash respresenting the issue can be split into three hashes: a hash of the concatenation of the hash representing the issue and the string "upvote"; a hash of the concatenation of the hash representing the issue and the string "downvote"; and, a hash of the concatenation of the hash representing the issue and the string "neutral". That allows this fundamental construct of approving an issue to be extended to an upvote/downvote of an issue (the most recent approval is the one that counts so that it wouldn't be possible to have both an upvote and a downvote). An upvote/downvote on a hash that represents a proposal could be interpreted as yea/nay on the proposal to determine whether the proposal should be accepted by the community. An upvote/downvote on a hash of a post could be used to determine its score in a style similar to Reddit. An upvote of a hash of a camp (with all relevant text included as part of the hash to prevent people from changing the meaning of the camp by editing the text after people vote) could be interpreted as the user supporting (or joining) that camp, while a more recent neutral vote could represent removing support of a camp they previously supported (leaving a camp). The hash extension concept can be expanded to have hashes representing any of the options of a poll (including the option of not voting for anything) where these hashes all ultimately depend on the hash of the data representing the poll. All kinds of possibilities exist. At the most general level the hash could simply be a hash of a ballot which itself includes the hash of an election. These ballots can then contain whatever information necessary to come to a consensus on the results of the election. And this method allows anyone who has the desire (assuming they can get access to all of the most recent, up to the limit of some snapshot deadline of course, raw signed data necessary from the websites or peers) to verify the results of all of these consensus systems independently using open source running on their computers. With enough skeptical people taking the time to do this and sounding the alarms if something is clearly wrong, most users can instead just trust the convenient results the website provides for most things and only bother to verify it themselves if it is a particularly important or controversial consensus result.


A "One share, one vote" canonization algorithm would definitely be the priority, but it would be great to enhance that so we could do things like bias the vote so people with fewer shares could have more of a vote, bias vote towards expertise/reputation, and anything else anyone would propose and we could build a near unanimous consensus around.

That is the beauty of the vote delegation system and liquid democracy. Someone with zero BTS could still get considerable voting power if they can convince the BTS stakeholders to delegate their voting power to him because they trust him to make smart decisions on their behalf that will grow the value of their stake. This person could even be paid by tips by these people to further incentivize him to do a good job and even use that income to grow his stake in BTS which even better aligns his incentives (and this system would allow users to optionally prove the amount of stake they have in their control by the way). And of course the stakeholders could always change the delegation of their stake at any time so the trusted user would know that he would lose that voting power if he makes decisions that go against the interests of the people delegating their voting power to him.

But ultimately the voting power needs to be derived from some initial source. If we want the source to be objective rather than subjective (so that we can actually come to a consensus), it cannot be based on how much each user is trusted because that is entirely subjective. It has to either come from: 1 BTS = 1 vote; 1 person = 1 vote (with trusted third-parties verifying who a unique person is); or some authority declaring by fiat what the voting weight of each user is. The last option is problematic for many reasons but one fundamental issue with it is the issue of how we even determine that authority figure in the first place. The second option also requires some trust in verifying the uniqueness of a human being (although that can be worked around to some extent). The second option is good for democracy applications that the voting DAC can be used for, but it is a bad idea for deciding the direction of a DAC since the stake of the DAC, the value of which will be affected by these decisions, are not uniformly distributed to each human being. I would imagine the second strategy can play a very important role in government and democracy related functions as well as perhaps determining the cultural zeitgeist through ranking regular discussion using Reddit style upvotes/downvotes, but it shouldn't be used to determine the strategic business decisions of a DAC (such as determining dilution caps or which marketing effort to spend the diluted BTS on). For those types of DAC decisions, I would say the most fair and sensible thing to do is to use the 1 BTS = 1 vote model but also allow the delegation of voting power as I described in this post so that people who trust others to make better decisions on their behalf can do so.


Offline Brent.Allsop

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




Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
Great, so are you going to take the initiative and add a "One BTS One Vote" algorithm into the list of Canonizer algorithms as well as the tools necessary to verify the signatures to allow users to prove stake ownership?

Absolutely.  It would definitely be possible to get this to do everything being proposed, and I will do everything in my power to code this and make it happen.

I must warn everyone that I have a full time job, and have other commitments, so the amount of time I can commit to this is limited.  If others could step up and help with this, we could get it up and running much faster.  There is quite a large list of things that need to be done to get this functional.

Currently, we do the canonization process in real time, every time someone loads the page.  I'd think we should be able to have a cashed snapshot of the block chain share ownership being constantly updated, and continue doing this in real time.

True, the text and structures of the camps, and such, would be centrally controlled and run on a server, but anyone would be able to validate any of the votes for these camps with appropriate tools, any time.  And that is the only thing that really needs to be on the block chain, at least to get started.  And my understanding is that the "vote" stuff being developed already does what we need.

A "One share, one vote" canonization algorithm would definitely be the priority, but it would be great to enhance that so we could do things like bias the vote so people with fewer shares could have more of a vote, bias vote towards expertise/reputation, and anything else anyone would propose and we could build a near unanimous consensus around.

















« Last Edit: November 02, 2014, 01:25:48 pm by Brent.Allsop »

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Canonizer would be fine if it did what I describe in the OP
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I have to admit Brent, whenever I used to see you plug your Canonizer website I'd sigh thinking "there he goes again...". But this time it seems relevant. This could actually be useful in this context..

Offline arhag

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

Great, so are you going to take the initiative and add a "One BTS One Vote" algorithm into the list of Canonizer algorithms as well as the tools necessary to verify the signatures to allow users to prove stake ownership? You would also need to have the accumulated score for each camp dynamically adjust everyday even without any camp changing occurring since BTS stake ownership can change on the blockchain and thus each user's stake voting power can fluctuate minute to minute. Then maybe someone else can modify the BitShares client to provide a three-click system of providing these signatures: the first click on a website launches the client with a request to provide signatures of all current valid BTS balances which will get associated to a specific website user name; the second click is to select the BTS account for which to provide the balance signatures (multiple clicks to select multiple accounts are also acceptable); and the third click is to confirm and have the client open the web browser with a HTTPS GET request to the website providing all the information it needs to know to update the user's voting power.

Obviously this isn't a great system since it would require trusting a third-party website to not fake the votes. The long term solution is to build all of this into the Vote DAC. But that is a long ways off and we could benefit from having a crude solution as soon as possible. This would be to just poll the users in a more accurate way than this forum's polls. Implementing actual hard fork changes to the blockchain would still require the 75% consensus voting mechanism on the blockchain that bytemaster has planned.

BTW, to the devs, it would also be really great if we had multisig as described here so that the hot client could update the voting power (and also change their votes for delegates) without exposing the important private keys on an online computer which could allow hackers to steal all of their funds.
« Last Edit: November 01, 2014, 11:32:09 pm by arhag »

Offline Brent.Allsop

  • Sr. Member
  • ****
  • Posts: 242
    • View Profile
    • Canonizer.com
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.
« Last Edit: November 01, 2014, 10:57:55 pm by Brent.Allsop »

Offline Pheonike

Let's call it the Community Consensus Mechanism v 0.1

Offline roadscape

2) Make a curated list of issues. Request a signature on (issue_id, decision) for each balance from users.
    A utility to create these signatures in bulk in a standard format is needed.

Don't we just need a wallet command for this? Or are you referring to making a 3rd party tool?
http://cryptofresh.com  |  witness: roadscape

zerosum

  • Guest
One thing I think it would be really great to have implemented ASAP would be a reddit style forum where people upvote and downvote with their stake (that they register by completing a cryptographic challenge at account creation or after). This would allow us to measure support for pretty much anything, even tiny issues, and it would make it easy for people to rapidly make many small variations of the same proposal/concept/idea and have stakeholders be able to conveniently rate all of them.

I think you should contact Agent86 directly with your proposal. He was very eager to implement something very similar on account level, a month or so ago.

As per my own take on the issues - we should drop all them stupid assets and stuff and concentrate on this only.


That does sound useful.
Exactly!, but Isn't this the point?

« Last Edit: November 01, 2014, 10:28:35 pm by tonyk2 »

Offline matt608

  • Hero Member
  • *****
  • Posts: 878
    • View Profile
One thing I think it would be really great to have implemented ASAP would be a reddit style forum where people upvote and downvote with their stake (that they register by completing a cryptographic challenge at account creation or after). This would allow us to measure support for pretty much anything, even tiny issues, and it would make it easy for people to rapidly make many small variations of the same proposal/concept/idea and have stakeholders be able to conveniently rate all of them.

Great idea. Very doable.

We wouldn't even need usernames.. votes and comments are just signed with a stake.


That does sound useful.

Having usernames makes it easier to judge comments and vote on them, I like to see who is making the comment so I can use my rough estimation of their intelligence + integrity (their general history) as a factor in judging what they are saying.

One problem might be if a large stakeholder downvotes a comment then it could get immediately buried (if it was done like reddit) without the chance to acruu upvotes.  Maybe there should be a brief time period (e.g. 1 hour, or 1 day?) after a comment before the votes take effect in terms of burying stuff no one likes and re-arranging popular stuff to the top.  Keep it in chronological order until that time period passes?  That's just for comments, for polls it could show up immediately.  Just a thought...
« Last Edit: November 01, 2014, 10:26:31 pm by matt608 »

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
One thing I think it would be really great to have implemented ASAP would be a reddit style forum where people upvote and downvote with their stake (that they register by completing a cryptographic challenge at account creation or after). This would allow us to measure support for pretty much anything, even tiny issues, and it would make it easy for people to rapidly make many small variations of the same proposal/concept/idea and have stakeholders be able to conveniently rate all of them.

Great idea. Very doable.

And yes any such service is only suited for business.
We wouldn't even need usernames.. votes and comments are just signed with a stake.

toast--
Wouldn't we need to announce vote snapshots?
Otherwise if BTS flows around, the vote does not follow.
Or, someone could "double-vote" if we counted votes between multiple daily snapshots.

You have one vote per snapshot + voting period. You need to make a new snapshot every day and get new signatures from each balance for that day.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline roadscape

One thing I think it would be really great to have implemented ASAP would be a reddit style forum where people upvote and downvote with their stake (that they register by completing a cryptographic challenge at account creation or after). This would allow us to measure support for pretty much anything, even tiny issues, and it would make it easy for people to rapidly make many small variations of the same proposal/concept/idea and have stakeholders be able to conveniently rate all of them.

Great idea. Very doable.

And yes any such service is only suited for business.
We wouldn't even need usernames.. votes and comments are just signed with a stake.

toast--
Wouldn't we need to announce vote snapshots?
Otherwise if BTS flows around, the vote does not follow.
Or, someone could "double-vote" if we counted votes between multiple daily snapshots.
http://cryptofresh.com  |  witness: roadscape

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
I don't know how the VOTE daap will work, but isn't what your asking covered by its functions? 

Anti-constitution rant:
As for a constitution... I urge big changes to wait until voting is implemented.  'Constitution' is a very powerful word.  It's a founding document.  It's the core protocol of a society.  It means starting all over again.   In the spirit of not having more drastic changes, to create calmness and investor confidence, using such dramatic words like calling a temporary description of bitshares the 'constitution' needs to stop.

Once power is truly distributed among the stakeholders people can propose whatever they like and if a constitution is an idea that gains traction it may come into existence.

As of now, stakeholders have self-selected themselves into bitshares just fine, as well as into every other investment in the history of man kind without a constitution.  So I am against having one.  Constitutions are for governments, not corporations whether they a decentralised or not.  The only rule is there are no rules.  What is this 'constitution' if it doesn't have to be obeyed?  It's just a confusing document that will divide the community.  I say voting is for choosing delegates, keep it modular.  Please do not create some monolithic and highly controversial document to alienate the current investors.

People will describe bitshares in different ways.  There's no need for there to be the 'one true description'.  It's already an elegant system, more changes to the foundation are harmful - and creating a constitution is a foundational shift!  Delegates (and currently 3I) need a description to use for marketing, of course, but calling it a constitution implies it has supreme importance when in reality it's just sales copy.

Bitshares has an elegant system, what it needs is for the foundation to stop changing, it isn't adaptation, it's floundering.

I agree with you. Big changes like this should wait until we have voting capability and that voting capability is tested. Most people probably wont vote right now and it's also not the idea time to create something like this when we don't even know what capabilities a DAC has yet.

It's a good time to discuss how to do it and work on the technology for it (voting).
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I actually like the idea that if a proxy delegate gets voted in it starts messing things up. This means that it can be used as a form of digital protest, if a large group of stakeholders feel they are being seriously mistreated. Obviously if it is not an issue that is very controversial then the supporters would never actually let it become a real delegate because they would be hurting their own investment. If both a yes proxy and a no proxy end up being really close to getting voted in, then that can serve as a signal that a "referendum" is needed with all stakeholders being pushed a notification asking them to vote on the issue through the hard fork voting system.

I think this is just getting messy. The idea of breaking the system could inhibit stakeholders from voting. Then you have to worry about some stake still voting for the dummy delegate even after the resolution, instead of voting for real delegates. Whoever sets up the delegate will start getting the inflation BTS after the hard fork... there is probably even more messy consequences neither of us can see.

I do not think we should pollute the Delegate voting space, as it may be difficult to clean up after ourselves completely.

No one would ever vote for a proxy delegate with a pay rate above 0. Anyway this is most definitely a hack, but I think it will do fine until more sophisticated methods are created (which I suspect won't be trivial to implement and get people to use).

One thing I think it would be really great to have implemented ASAP would be a reddit style forum where people upvote and downvote with their stake (that they register by completing a cryptographic challenge at account creation or after). This would allow us to measure support for pretty much anything, even tiny issues, and it would make it easy for people to rapidly make many small variations of the same proposal/concept/idea and have stakeholders be able to conveniently rate all of them.

The only important thing to remember with such a system is that the stake voting on posts and comments should only be done for "business things". If the platform is used for social communication or link sharing then that functionality should be clearly segregated into a separate system where voting is more like traditional reddit (perhaps with advanced individual filtering features), but stake should never have a say in controlling what kind of social/cultural expression the community presents to itself and others.

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
The BTS blockchain is used to secure one consensus measure: percent ownership. The only purpose of a "constitution" is to define an initial social consensus to let stakeholders self-select into it. BTS ownership is already well-defined but its goals are not clear yet. Once a DAC is being traded, the will of its majority stakeholders can change and that will change the actions of the DAC. You can choose to still claim there's a constitution to help explain what the expected behavior of the DAC is based on its current shareholders, but the technology does not recognize it.

The blockchain can be used to document decisions about stakeholder intent that becomes impossible to muddle in the future. Once we get things figured out using off-chain systems that don't require core dev time, we can move more governance functions into the actual BTS client.

It would be good if a dev could do this:

1) Take daily BTS snapshots to obtain a map from address to amount
2) Make a curated list of issues. Request a signature on (issue_id, decision) for each balance from users. A utility to create these signatures in bulk in a standard format is needed.
3) Keep a running total of votes for each issue, allowing people to change the vote of a balance during the day.
4) Test actively, and start using it to make real decisions to force stakeholder engagement

Once this is in place we can start refining how the will of BTS leader+whale hivemind can be computed

I like this and it's moving in the right direction.
I'm not really someone who thinks we should rush into a constitution but I do think we should figure out how to give stakeholders more of voice on different issues.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline roadscape

What has to happen for a developer to actually attack this starting right now? An escrowed bitUSD commitment?

I am going to hack on it tonight.
http://cryptofresh.com  |  witness: roadscape

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I actually like the idea that if a proxy delegate gets voted in it starts messing things up. This means that it can be used as a form of digital protest, if a large group of stakeholders feel they are being seriously mistreated. Obviously if it is not an issue that is very controversial then the supporters would never actually let it become a real delegate because they would be hurting their own investment. If both a yes proxy and a no proxy end up being really close to getting voted in, then that can serve as a signal that a "referendum" is needed with all stakeholders being pushed a notification asking them to vote on the issue through the hard fork voting system.

I think this is just getting messy. The idea of breaking the system could inhibit stakeholders from voting. Then you have to worry about some stake still voting for the dummy delegate even after the resolution, instead of voting for real delegates. Whoever sets up the delegate will start getting the inflation BTS after the hard fork... there is probably even more messy consequences neither of us can see.

I do not think we should pollute the Delegate voting space, as it may be difficult to clean up after ourselves completely.
« Last Edit: November 01, 2014, 09:17:15 pm by fluxer555 »

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
What has to happen for a developer to actually attack this starting right now? An escrowed bitUSD commitment?
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I agree with everything you're saying, I'm just pointing out that if delegates are supposed to represent stakeholder intent then the fact that there are not explicit "no policy" delegates shows it is probably failing to really represent BTS holder desires. I suppose the init delegates played that role at the start, but not anymore.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline roadscape

This idea is a perfect for an off-the-blockchain app.

It's a stop-gap measure until VOTE, no need to change fundamentals.
http://cryptofresh.com  |  witness: roadscape

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Perhaps we can have BM help with whatever servers the 'init' delegates are running on, to create new dummy delegates that will produce blocks just fine, that we can use for the purpose of voting for proposals.

I actually like the idea that if a proxy delegate gets voted in it starts messing things up. This means that it can be used as a form of digital protest, if a large group of stakeholders feel they are being seriously mistreated. Obviously if it is not an issue that is very controversial then the supporters would never actually let it become a real delegate because they would be hurting their own investment. If both a yes proxy and a no proxy end up being really close to getting voted in, then that can serve as a signal that a "referendum" is needed with all stakeholders being pushed a notification asking them to vote on the issue through the hard fork voting system.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I think the easiest way to do this would to have proxy delegates for an issue you want to stake poll.

So when you want to ask if e.g. dilution is good, then you make two delegates and put approval links in the post btsx:yes.dilution.proxyabc/approve and btsx:no.dilution.proxyabc/approve

Then it should be fairly easy to gauge stakeholder sentiment based on the votes the proxy delegates receive.

That's a pretty good technique but you can't distinguish between active and inactive stake. You can only count active supporters and compare support for alternative ways to do things.

Well you can compare with the current active delegates. If it becomes apparent that a proxy delegate is going to get voted in (or even is voted in and starts screwing with the block production temporarily), then I don't think it can plausibly be argued that there could be an active majority against the proposal.

But even at much smaller numbers just comparing with the lowest voted current active delegate should give a good picture of how much active support or objection an issue has, especially if you also compare the ratio of people voting for the yes proxy and the no proxy.

I would agree with you if the delegate list was full of no-policy at-cost delegates. Delegates are not a perfect substitute for proposal executives because "no action" delegate requires an operator.

You mean a "no proxy" delegate requires someone to register it in the first place, and a guy with a proposal will register only the yes proxy delegate? If there is an active majority against the proposal then they will certainly move to campaign against it and create a proxy delegate against it if they observe its yes proxy getting too many votes. IMO the barriers of entry for doing this are so low it wouldn't require any special inbuilt support from the blockchain (at least in the short term). You don't have to actually install or run a delegate just to register one that people can vote for, right?

But even if it wasn't that easy for the opposition campaign to register a no proxy, I don't think anyone, delegates or stakeholders, would take a proposal seriously in the first place if it was initially presented with only the possibility for people to vote "yes". Even stakeholders that were strongly supporting it would find that kind of trickery ludicrous.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
Perhaps we can have BM help with whatever servers the 'init' delegates are running on, to create new dummy delegates that will produce blocks just fine, that we can use for the purpose of voting for proposals.
« Last Edit: November 01, 2014, 08:57:32 pm by fluxer555 »

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I think the easiest way to do this would to have proxy delegates for an issue you want to stake poll.

So when you want to ask if e.g. dilution is good, then you make two delegates and put approval links in the post btsx:yes.dilution.proxyabc/approve and btsx:no.dilution.proxyabc/approve

Then it should be fairly easy to gauge stakeholder sentiment based on the votes the proxy delegates receive.

That's a pretty good technique but you can't distinguish between active and inactive stake. You can only count active supporters and compare support for alternative ways to do things.

Well you can compare with the current active delegates. If it becomes apparent that a proxy delegate is going to get voted in (or even is voted in and starts screwing with the block production temporarily), then I don't think it can plausibly be argued that there could be an active majority against the proposal.

But even at much smaller numbers just comparing with the lowest voted current active delegate should give a good picture of how much active support or objection an issue has, especially if you also compare the ratio of people voting for the yes proxy and the no proxy.

I would agree with you if the delegate list was full of no-policy at-cost delegates. Delegates are not a perfect substitute for proposal executives because "no action" delegate requires an operator.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I think the easiest way to do this would to have proxy delegates for an issue you want to stake poll.

So when you want to ask if e.g. dilution is good, then you make two delegates and put approval links in the post btsx:yes.dilution.proxyabc/approve and btsx:no.dilution.proxyabc/approve

Then it should be fairly easy to gauge stakeholder sentiment based on the votes the proxy delegates receive.

That's a pretty good technique but you can't distinguish between active and inactive stake. You can only count active supporters and compare support for alternative ways to do things.

Well you can compare with the current active delegates. If it becomes apparent that a proxy delegate is going to get voted in (or even is voted in and starts screwing with the block production temporarily), then I don't think it can plausibly be argued that there could be an active majority against the proposal.

But even at much smaller numbers just comparing with the lowest voted current active delegate should give a good picture of how much active support or objection an issue has, especially if you also compare the ratio of people voting for the yes proxy and the no proxy.
« Last Edit: November 01, 2014, 08:36:49 pm by Rune »

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I think the easiest way to do this would to have proxy delegates for an issue you want to stake poll.

So when you want to ask if e.g. dilution is good, then you make two delegates and put approval links in the post btsx:yes.dilution.proxyabc/approve and btsx:no.dilution.proxyabc/approve

Then it should be fairly easy to gauge stakeholder sentiment based on the votes the proxy delegates receive.

That's a pretty good technique but you can't distinguish between active and inactive stake. You can only count active supporters and compare support for alternative ways to do things.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline matt608

  • Hero Member
  • *****
  • Posts: 878
    • View Profile
I don't know how the VOTE daap will work, but isn't what your asking covered by its functions? 

Anti-constitution rant:
As for a constitution... I urge big changes to wait until voting is implemented.  'Constitution' is a very powerful word.  It's a founding document.  It's the core protocol of a society.  It means starting all over again.   In the spirit of not having more drastic changes, to create calmness and investor confidence, using such dramatic words like calling a temporary description of bitshares the 'constitution' needs to stop.

Once power is truly distributed among the stakeholders people can propose whatever they like and if a constitution is an idea that gains traction it may come into existence.

As of now, stakeholders have self-selected themselves into bitshares just fine, as well as into every other investment in the history of man kind without a constitution.  So I am against having one.  Constitutions are for governments, not corporations whether they a decentralised or not.  The only rule is there are no rules.  What is this 'constitution' if it doesn't have to be obeyed?  It's just a confusing document that will divide the community.  I say voting is for choosing delegates, keep it modular.  Please do not create some monolithic and highly controversial document to alienate the current investors.

People will describe bitshares in different ways.  There's no need for there to be the 'one true description'.  It's already an elegant system, more changes to the foundation are harmful - and creating a constitution is a foundational shift!  Delegates (and currently 3I) need a description to use for marketing, of course, but calling it a constitution implies it has supreme importance when in reality it's just sales copy.

Bitshares has an elegant system, what it needs is for the foundation to stop changing, it isn't adaptation, it's floundering.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I think the easiest way to do this would to have proxy delegates for an issue you want to stake poll.

So when you want to ask if e.g. dilution is good, then you make two delegates and put approval links in the post btsx:yes.dilution.proxyabc/approve and btsx:no.dilution.proxyabc/approve

Then it should be fairly easy to gauge stakeholder sentiment based on the votes the proxy delegates receive.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
There's not a quick and easy way to prevent people form being able to group balances together. There's some analysis you can't avoid just by the nature of stake-vote.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline roadscape

I was thinking more like a simple web app + python script for now, something crude you could make fast

I'm interested. Sounds like a good learning project.

What's a good way to preserve anonymity when a signed vote is submitted? Other than not recording IP addresses..
http://cryptofresh.com  |  witness: roadscape

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I was thinking more like a simple web app + python script for now, something crude you could make fast
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
Idea:

A Chrome extension that automatically scans any page from bitsharestalk.org for some standard-syntax issue_ID and pops up with a little thing on the side asking for your decision. This plugs into your RPC client and sends off the vote.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
The BTS blockchain is used to secure one consensus measure: percent ownership. The only purpose of a "constitution" is to define an initial social consensus to let stakeholders self-select into it. BTS ownership is already well-defined but its goals are not clear yet. Once a DAC is being traded, the will of its majority stakeholders can change and that will change the actions of the DAC. You can choose to still claim there's a constitution to help explain what the expected behavior of the DAC is based on its current shareholders, but the technology does not recognize it.

The blockchain can be used to document decisions about stakeholder intent that becomes impossible to muddle in the future. Once we get things figured out using off-chain systems that don't require core dev time, we can move more governance functions into the actual BTS client.

It would be good if a dev could do this:

1) Take daily BTS snapshots to obtain a map from address to amount
2) Make a curated list of issues. Request a signature on (issue_id, decision) for each balance from users. A utility to create these signatures in bulk in a standard format is needed.
3) Keep a running total of votes for each issue, allowing people to change the vote of a balance during the day.
4) Test actively, and start using it to make real decisions to force stakeholder engagement

Once this is in place we can start refining how the will of BTS leader+whale hivemind can be computed
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.