I have voting turned off as I realize that's a dead giveaway.
I think we really need a solution to this that could work with blinded values without compromising privacy much. Otherwise, people who really care about privacy won't vote to the detriment of the network.
I already discussed this elsewhere but I think it is important to allow some semi-trusted third party to claim vote tallies from the blinded BTS balances of some selection of accounts. But it has to be done in a way that prevents the third party from changing the votes (they could only choose to exclude accounts from the vote tally, but not use their stake to vote for someone the stakeholder didn't vote for). So let's say some subset of accounts with blinded BTS balances decide to elect a particular third party to see their BTS balance (by privately sharing the blinding factor with the third party) and aggregate their vote. The third party would specify the account IDs of all the account's vote it will be aggregating. It will also specify a blacklist of delegates/witnesses/workers that it will not aggregate votes for because not enough of the specified accounts are voting for that delegate/witness/worker (which would compromise privacy for the few accounts in the selection that were voting for that delegate/witness/worker). Then for each member in the union of the delegates/witnesses/workers that were included in the votes of the selected accounts, the third party provides a plain-text stake tally and proof that the sum is valid. This proof is a commitment of the tally and a signature proving that fact, where the blinding factor of the commitment is selected so that the sum of commitments of the BTS balances for all accounts voting for the specific delegate/witness/worker (subtracted by the sum of the commitments of the BTS balances for all accounts voting against the specified worker, in the specific case of workers since they can be downvoted) equals the commitment of the tally provided as part of the proof. In other words, for each member X (delegate/witness/worker) add all the blinding factors of accounts approving of X and, if X is a worker, subtract all the blinding factors of accounts disapproving of X to get the blinding factor for the commitment to the tally. This transaction only needs to be provided to the blockchain once per maintenance period to save costs (it is okay if there is even a 1 day delay in incorporating all the votes).
The good thing about this approach is that the third-party cannot lie about the votes (only exclude them). Aggregating the vote results from different third-parties is problematic for the blockchain if the selections of accounts for each of the aggregates have some overlap. The blockchain can always ignore valid vote tally transactions for the same maintenance period from third parties if their account selections are a subset of that of a valid vote tally transaction of the same maintenance period from another third party. But when neither account selection of two different valid tally transactions are a subset of the other but yet do still overlap, the blockchain is forced to ignore at least one of them. To avoid this, each account should only choose one third party to aggregate their vote at any given time. This selection by each account could be recorded on the blockchain, so that any vote tally transaction by a third party trying to include the votes of an account that has not specified them as the third party that is allowed to aggregate their vote is automatically dismissed as invalid. Furthermore, the accounts could publicly put some money in a fund specifically to economically motivate the third party to include them into the vote tally. The third party including an account into the aggregation of a vote tally transaction could withdraw a specific amount of funds from that account. The account may automatically pay the third party some small fee from the fund each day for each delegate/witness/worker that they voted for and that was included (meaning not blacklisted) into the vote tally for the day by the designated third party.
One way to make this better would be if the cryptography could allow each account to publish information on the blockchain that proves that they publicly provide enough information for someone who knows the private key corresponding to some specified public key (the public key of the third party in this case) to be able to derive the blinding factor for the account's BTS balance commitment (but without actually revealing the blinding factor to anyone else who doesn't possess that private key). If the cryptography could be designed this way (some kind of zero knowledge proof), then the blockchain could assume that the owner of that private key (the third party) would include all accounts which provide such valid proofs in their vote tally transaction and had set a maximum pay per day per voting item that was more than or equal to the minimum threshold defined by the third party (and of course had enough funds set aside to pay for that cost of including their votes in the vote tally transaction for that day). This would mean that the third party would not need to specify a long list of account IDs as part of the daily vote tally transactions (meaning smaller transaction size and lower costs). Obviously in that situation the third party would be forced to include the votes (with the exception of blacklisted delegate/witness/worker votes that hardly anyone voted for) of every account that elected them to aggregate the vote and provided the valid proof and had enough funds designated for the purpose of paying the necessary costs, since that is what the blockchain protocol would expect from the vote tally transaction submitted by the third party.
Topic: What if BitShares could have perfect privacy? (Read 17479 times)
