I question your assumption that it is not possible for voters to make provable public what they have voted for without loosing control of the coins.
You argue that users encrypt their votes and release the private key only when all votes are placed - since otherwise someone else could control the vote (the TRU?)
However, as far as I understood the timeframe for placing a vote is in the range of days while the timeframe for a block creation is more like 10 minutes (??). Now - when my vote is in the blockchain (together with a (not encrypted) transaction to a different address, right?) what prevents me from publishing the private key?
The version of truthcoin that I wrote avoids this step. I never reveal the private keys at all, and it is for exactly the reason you suggest.
Instead, the private key is used to sign the transaction.
https://github.com/zack-bitcoin/Truthcoin-POW
If you did, someone could publish an 'update' changing your vote (to either something nonsensical, so that you would lose in RBCR, or to the realistic Ballot) and at the same time steal your "VoteCoins".
Quote from: Whitepaper1.2
Voters encrypt, sign, and broadcast a Ballot which contains their Votes and a new public key (for which they have the corresponding private key). Critically, Voters have the option to change their Ballot at any time and for any reason during this period (for example, to update the new public key). Only the latest included Ballot stands.
The transaction
is encrypted.
https://github.com/psztorc/Truthcoin/tree/master/docs#do-strategic-decisions-change-if-one-node-started-publishing-potentially-biased-votes-immediately-upon-noticing-them-one-could-publish-10-attack-votes-and-the-11th--user-would-be-tempted-to-conform-leading-to-a-cascading-failure
Quote from: zack on August 21, 2014, 10:52:31 PM
The version of truthcoin that I wrote avoids this step. I never reveal the private keys at all, and it is for exactly the reason you suggest.
Instead, the private key is used to sign the transaction.
https://github.com/zack-bitcoin/Truthcoin-POW
Can you be more specific about what you omitted?
unspent transactions are not encrypted. They are publicly visible. The blockchain doesn't know about them yet.
If there was a private key in an unspent transaction, then anyone who read it would be able to generate more valid unspent transactions for the same ID. It is ID-theft.
I had forgotten that you do every transaction in 2 steps.
Yes, you can reveal private keys this way, and it is secure.
I don't like it though, so I didn't do it that way.
Users in my system are identified by addresses which are generated from their public key.
With your method, I would have to allow users to purchase custom names for identification?
Bitcoin requires 120 blocks before new money is spendable.
Otherwise forks would delete money sometimes.
How many blocks between when you encrypt a transaction, and when you reveal it?
Whenever there is a big fork, everyone who revealed private keys would be vulnerable to theft
I am not sure if it is true for all possible implementations of encrypting messages, but I think in general it is possible to prove to others the content of an encrypted message without revealing the key? - https://en.wikipedia.org/wiki/Zero-knowledge_proofs
From reading in my spare time, I gathered that for symmetric key encryption it is probably not possible to show someone [1] an unencrypted message, [2] an encrypted message, [3] some proof that #2 really is the encrypted form of #1, without revealing [4] the encryption secret.
I'm excited for real cryptographers to look at this schedule, because I'm highly confident that it will be substantially changed for the better. We may not even need to send votes in two waves at all, or wait for a long time, or expose private keys. There is probably a fancier cryptography way to do all of this which, in the planning stages, we can easily implement.
Quote from: psztorc on August 22, 2014, 01:34:57 PM
real cryptographers
So what do you think I am?
Quote from: psztorc on August 22, 2014, 01:34:57 PM
fancier cryptography
the only crypto used for projects like this is public key crypto (for creating signatures, and verifying signatures), and hash algorithms.
It is possible to build a cryptocurrency from only hash algorithms, but it is a little less efficient, and the code is a little messier.
You instead use encryption and decryption. Those tools are totally avoided for a project like this.
I cannot see any reason for them to exist, and my implementation does not use them at all.
Truthcoin as I built it does not need to send votes in two waves, or wait a long time, or expose private keys.
I not sure wether the vote encryption is substantial at all.
Of course: your argument that it is needed is that it should make collusion/ coordination on something else but the truth more difficult.
However - I suspect people (or at least some major coin holders) to publish feeds with their ballot since it is in their interest that lots of others vote "close" to them so they profit from RBCR. OK - you might argue they profit from some outliers even more but I think first it is more important to be close to the vector that results in the SVD.
Thus said people some people will publish votes anyway and it is reasonable to trust them (if they have some reputation) So - would not encrypting the votes would really make a difference? Remember: votes are not binding!! You always can change them - so - from a game theory point of view - the difference between a (not binding) visible vote in the blockchain - vs a encrypted vote + a feed of it is not that big as all (or maybe there is no difference at all). Since if people want to trick on other they can - in option 1: publish something different in the external source/ in option 2: change their votes in the last second.
Of course - at lot of people will - because of laziness not provide a feed of their votes - but the pure nash equilibrium should be the same for both versions?
(And I guess a equilibrium strategy might be: always publish all your votes but with 3%-5% intentional errors)
Actually, all the voters have an incentive to lie to each other, and trick each other to vote incorrectly.
It is the only incentive structure that is safe from collusion.
Each block has a finite capacity for votes. If everyone changes votes at the last second, then a lot of transactions wouldn't get included.
It would be a very risky game to play, you could end up voting the wrong way. Also, each transaction has a fee...
People who live in remote locations with poor connection wouldn't be able to broadcast a vote at the last minute. There is too much delay.
My current implementation has a 20-block cycle.
The first 10 blocks are when voters share the hash of their vote.
The next 5 blocks are when voters reveal the vote, and it has to match the hash they shared earlier.
The last 5 blocks are when it is possible to do single-value-decomposition to determine the consensus outcomes of each decision.
My way of doing "encrypted" votes doesn't involve encryption. It is more like
one other thing I forgot is: miner censorship of votes.
So forget about publicly visible votes.
Quote from: zack on August 24, 2014, 02:14:53 AM
Actually, all the voters have an incentive to lie to each other, and trick each other to vote incorrectly.
I am not 100% sure to me if this is true. I think the first it is important for voters that a decent number of votes is very similar to them. So why not publish the own true votes. Lets say 60-70% copy the votes and all other does it for themselves every one in the 70% would profit. And since it is a "repeated game" there is no real incentive to lie to your "70% crowd". Only as soon as 100% of the voters follow you, you would stop profiting from RBCR.
Quote from: zack on August 24, 2014, 02:14:53 AM
The first 10 blocks are when voters share the hash of their vote.
So in your implementation voters could reveal their vote without loosing control over it, right?
Quote from: koeppelmann on August 24, 2014, 03:46:18 PM
one other thing I forgot is: miner censorship of votes.
So forget about publicly visible votes.
How does encrypting the votes help with miner censorship?
Miners could censor the decryption steps that they dislike just as easily as they could censor the encrypted-vote steps.
Quote from: koeppelmann on August 24, 2014, 03:46:18 PM
So in your implementation voters could reveal their vote without loosing control over it, right?
I don't understand the question...
In my implementation, you never have to reveal your private key.
Quote from: zack on August 24, 2014, 07:52:31 PM
Quote from: koeppelmann on August 24, 2014, 03:46:18 PM
one other thing I forgot is: miner censorship of votes.
So forget about publicly visible votes.
How does encrypting the votes help with miner censorship?
Miners could censor the decryption steps that they dislike just as easily as they could censor the encrypted-vote steps.
If votes would be not encrypted (or hashed) miners could influence the outcome of the vote by not adding votes they don't like into the blocks/blockchain. Since votes are hashed/ encrypted they don't know what they are adding.
Quote from: zack on August 24, 2014, 07:52:31 PM
Quote from: koeppelmann on August 24, 2014, 03:46:18 PM
So in your implementation voters could reveal their vote without loosing control over it, right?
I don't understand the question...
In my implementation, you never have to reveal your private key.
The assumption in Pauls paper is that voters can not reveal their vote early to others without loosing control over their vote /(publishing a private key). I guess in your implementation that does not hold true since voters CAN PUBLISH THE VOTE ON AN EXTERNAL SOURCE before the official vote reveal phase.
However - as mentioned earlier - since they still could change their vote in the last minute I think the assumption from the paper that trustless collusion is not possible still holdes true.
Quote from: koeppelmann on August 24, 2014, 08:02:57 PM
Quote from: zack on August 24, 2014, 07:52:31 PM
Quote from: koeppelmann on August 24, 2014, 03:46:18 PM
one other thing I forgot is: miner censorship of votes.
So forget about publicly visible votes.
How does encrypting the votes help with miner censorship?
Miners could censor the decryption steps that they dislike just as easily as they could censor the encrypted-vote steps.
If votes would be not encrypted (or hashed) miners could influence the outcome of the vote by not adding votes they don't like into the blocks/blockchain. Since votes are hashed/ encrypted they don't know what they are adding.
miners could influence the outcome of the vote by not adding decryptions they don't like into the blockchain. Since the decryption is not hashed/encrypted, everyone knows what is being added.
Quote from: koeppelmann on August 24, 2014, 08:02:57 PM
The assumption in Pauls paper is that voters can not reveal their vote early to others without loosing control over their vote /(publishing a private key). I guess in your implementation that does not hold true since voters CAN PUBLISH THE VOTE ON AN EXTERNAL SOURCE before the official vote reveal phase.
However - as mentioned earlier - since they still could change their vote in the last minute I think the assumption from the paper that trustless collusion is not possible still holdes true.
You are correct. It is also possible to write an incorrect vote to trick people, and then refuse to decrypt the vote later on.
Everyone has strong incentive to trick each other.
Quote from: zack on August 24, 2014, 10:57:55 PM
Quote from: koeppelmann on August 24, 2014, 08:02:57 PM
Quote from: zack on August 24, 2014, 07:52:31 PM
Quote from: koeppelmann on August 24, 2014, 03:46:18 PM
one other thing I forgot is: miner censorship of votes.
So forget about publicly visible votes.
How does encrypting the votes help with miner censorship?
Miners could censor the decryption steps that they dislike just as easily as they could censor the encrypted-vote steps.
If votes would be not encrypted (or hashed) miners could influence the outcome of the vote by not adding votes they don't like into the blocks/blockchain. Since votes are hashed/ encrypted they don't know what they are adding.
miners could influence the outcome of the vote by not adding decryptions they don't like into the blockchain. Since the decryption is not hashed/encrypted, everyone knows what is being added.
good point!
However, I think this typ of censorship is not that bad, since voters have a period to include votes in the blockchain.
So the power of a mining pool is limited. They can block certain votes - but it wouldn't have any effect as long as one honest miner finds a block during the "reveal phase".
With unencrypted votes/ not hashed votes it would be a hole different story - since the mining pool that would make the latest block could add votes/ vote changes in a selfish way.
Quote from: zack on August 24, 2014, 10:57:55 PM
Quote from: koeppelmann on August 24, 2014, 08:02:57 PM
Quote from: zack on August 24, 2014, 07:52:31 PM
Quote from: koeppelmann on August 24, 2014, 03:46:18 PM
one other thing I forgot is: miner censorship of votes.
So forget about publicly visible votes.
How does encrypting the votes help with miner censorship?
Miners could censor the decryption steps that they dislike just as easily as they could censor the encrypted-vote steps.
If votes would be not encrypted (or hashed) miners could influence the outcome of the vote by not adding votes they don't like into the blocks/blockchain. Since votes are hashed/ encrypted they don't know what they are adding.
miners could influence the outcome of the vote by not adding decryptions they don't like into the blockchain. Since the decryption is not hashed/encrypted, everyone knows what is being added.
Quote from: koeppelmann on August 24, 2014, 08:02:57 PM
The assumption in Pauls paper is that voters can not reveal their vote early to others without loosing control over their vote /(publishing a private key). I guess in your implementation that does not hold true since voters CAN PUBLISH THE VOTE ON AN EXTERNAL SOURCE before the official vote reveal phase.
However - as mentioned earlier - since they still could change their vote in the last minute I think the assumption from the paper that trustless collusion is not possible still holdes true.
You are correct. It is also possible to write an incorrect vote to trick people, and then refuse to decrypt the vote later on.
Everyone has strong incentive to trick each other.
I'm a bit late to the party here, but I can't help but think about koeppelmann's comment. Who says that the malicious collaborators are all independent entities that have no idea who each other are? All you need is a single malicious group, or single malicious person (with enough wallets), to acquire most of the VoteCoins. Do you think the market cap for VoteCoins would be so high that it would prohibit a single person or single group from accumulating a majority of the VoteCoins on the open market? It seems to be that it is a lot easier to launch a 51% attack on TruthCoin PMs by simply accumulating a majority stake in the VoteCoin market, than it would be to, say, launch a 51% attack on Bitcoin by accumulating 51% of the hashing power.
I just read through the whitepaper and associated documents yesterday. Really, really intrigued by this project. I keep seeing the voting system as the weakest piece though, which is the key that everything else relies on. In order for people to put trust into this decentralized system it has to be a practical impossibility that an incorrect outcome could ever be decided.
Hi Troy,
I completely agree with you. In fact, extra security to prevent against the ">51% ownership attack" has been really the only change I have been making to the design since I first published the initial code nearly a year ago.
You may have noticed (if you read the latest whitepaper) that 51% is now actually not enough...I have something represented by the greek Phi (I think) which is responsible for the "Two Wave SVD" concept (or DoubleFactory() in the R code). This helps to extend the incentives present until 49% all the way up to Phi%. However, now someone with (1-Phi)% can delay Decision-Resolution. For this I have the Audit concept (a "Branch" of cash), and to that I've added a careful Miner Veto. These changes will be published in new slides (hopefully tomorrow, but who knows), and in Whitepaper 1.4, which I hope to publish before Wednesday evening (although I doubt I'll pull that off).
In general, I think the strategic principle of "time" is sound. It is harder to hide information as time passes, yet funds can be frozen in place. The net effect is always to make the attacker's life more inconvenient. Because the network has value, this inconvenience can be transformed into a disincentive.
And I am hoping to contrive Branching, such that it is rare to actually pull off, keeping all the Market Caps of each Branch very high.
And, I don't think you are late to the party.
In fact I'd say the party hasn't even started yet.
My version of truthcoin is a little different. Anyone can create a new branch by burning some cashcoin.
The branches are in competition with each other for customers. The branch jurors will do whatever they need to do to show how honest they are.
Whichever jury is best able to prove it's honesty, that jury will get the most customers and make the most profit.
It is possible to create a prediction market using decisions from multiple branches.
Not all types of votecoins will be on exchanges. Some juries might never transfer their votecoins after the initial allocation.
@zack - but the voting mechanics/ coin redistribution/ SVD stuff, does work the way as Paul proposed it for every individual jury/branch, right? Even if it is only a single entity holding all votecoins of one branch?
If only one person holds all the votecoins, then we cannot even compute SVD. the matrix is a vector.
A single person could have 3 accounts, and they could split the votecoins among them. Then that single person could have complete control on the outcome of the predictions they host.
Those predictions would be total scams.
It is a market where the buyers need to be aware of the danger.
But, honest juries will come up with many techniques to make themselves look most honest.