BTS Governance step 1: Basic stake polling

[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

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

[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'.

[Brent.Allsop]

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

[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

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

[Brent.Allsop]

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

[Brent.Allsop]

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.

[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

I've posted a feature request on 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

[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?

[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)

[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.

[Agent86]

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.

[toast]

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.

[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.

[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:

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.