51% of hashrate could give you control over all vote-coins?

[koeppelmann]

As far as I understood: the valid blockchain is the blockchain where the most POW AND the most votes are put in.

from the paper: there is the timeline
5) Market Matures – votes are encrypted in the blockchain
6) Votes Decrypted – private keys are revealed

What an miner attacker with 51% could do: after the private keys are revealed: build up a new blockchain. Start in the latest block of phase 5) update all votes with the revealed private keys, (change votes to whatever he want - but more important transfer votecoins to own addresses)
Now he can build up a higher blockchain since it could have ALL VOTES and MORE HASHRATE

Did I overlook something?

[psztorc]

Its all PoW, just like Bitcoin. The schedule I outlined has votes been put in over a week, then unsealed over a second week. That's like a 2000 block reorg.

Say group A is honest. If group B factions off to do a 1000 block reorg (which would pretty much destroy the project anyway), they have to worry about how many people they can get to join group B. Group C might form, simultaneously, so that only A = 40%, B = 30%, C = 30%. A is already 1000 blocks ahead and won't be overtaken.

Gavin has written lots of stuff about how 51% attacks can be further discouraged, but no one has implemented any of it because most people believe that 51% attacks are very unlikely.

[zack]

My truthcoin implementation does not reveal private keys. Instead, the key is used to sign the transaction.

I don't think you should ever force someone to reveal their private key.

Usually a 51% attack is not very threatening. It allows the attacker to spend some money twice.
The attack fails a large portion of the time, and it is very hard for the attacker to make more money than they lose.
Blockchains can survive traditional 51% attacks like this.

If a blockchain reveals private keys, then 51% attacks are MUCH scarier.
The attacker is able to steal ALL the coins, from everyone who revealed private keys.
The attacker would easily make more money than it loses, since it can steal so much from other coin-holders.
This would kill the blockchain, since every voter would lose everything.

[psztorc]

My truthcoin implementation does not reveal private keys. Instead, the key is used to sign the transaction.

Then how do you prevent voting cartels?

If a blockchain reveals private keys, then 51% attacks are MUCH scarier.

They are scarier, which is why I made the-scary-part proportionally more-difficult-to-pull-off.

Its as if you haven't read or understood the point of my design at all.

[zack]

Then how do you prevent voting cartels?

I answered this question here: http://forum.truthcoin.info/index.php/topic,26.msg494.html#msg494

summary:
I use hash function instead of encryption.

[psztorc]

Zack and I had the opportunity to speak off-forum. I am summarizing the conversation here for everyone's benefit.

Zack's proposal to use the hash did not quite work. However I was able to improve it slightly. There is still "furtive information" which must be hidden until a certain point in time, and, if revealed, would still give you some control over all VoteCoins (the ability to exclude them from one VotingPeriod and later steal them), but it does avoid revealing "private keys" which may be less discomforting. It costs a new transaction type (ie more complexity and potential for bugs).

The original "vote" contains either encrypted or hash of ( ballot + newPublicKey ), then, later, the "reveal" is submitted (ballot + newPublicKey are revealed). We can't work with the ballot, but we can work with newPublicKey. We can invent a new transaction type, called 'StealFromLoudVoters', which is of the form ( TargetReveal, VotersNewPublicKey, TheifNewPublicKey ). This transaction checks to see if a "reveal" contains the same "VotersNewPublicKey". If it does, that ballot changes to "All Missing" and the post-RBCR VoteCoins go to the "theif". The first StealFromLoudVoters to be included in a block wins.

No incentive to reveal the contents of the hash. No way to prove the first contents of the hash, without revealing the second half. No incentive to reveal the second half (votes will be stolen). No incentive to steal from yourself (all missing).

I'm not sure if it is worth it or what. I still think that a professional cryptographer / researcher will come up with a better way.

[zack]

I still dislike your method, because it involves switching public keys.
That is unnecessary. We can simply transfer funds from one address to another, instead of forcing everyone to change addresses all the time.

I think that adding a 10th transaction type is far less complicated than stretching a single transaction to do 2 such different things.
(1) revealing the votecoin vote
(2) punishing a votecoin holder for trying to cheat

Both ideas are very well understood alone.
(1) the classic "transaction puzzle" from bitcoin. The simplest script that is still useful: https://en.bitcoin.it/wiki/Script#Transaction_puzzle
(2) "slasher" from Vitalik's paper: https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/

Why don't you think I am a valid blockchain researcher?
The cryptography professor who's lab I work in cannot understand bitcoin. He just makes/breaks codes. Blockchains are a mystery to him. His advice is as worthless as fiat, but he is still more "professional" than me, since he is on a paycheck and I am jobless.

Cryptography for cryptocurrencies is very limited. I don't have a proof, but I am certain that a secure hashing function like SHA256 is the only cryptography needed to build any blockchain. I also use ECDSA secp256k1 for signatures, as Satoshi did, because it makes some things much simpler.

A game-theorist could know a lot of stuff I do not know, and could give useful suggestions for how to stop voting collusion. I cannot imagine any cryptographer capable of giving me a useful suggestion for truthcoin. Perhaps "cryptography" means something very different for you and I.

To me, asking a cryptographer to help with making a blockchain is like asking a theoretical physicst for help building a bridge.
The professor for my lab is very good at building secure hashing algorithms, but we already have SHA256, and I can use that as well as he can. He couldn't tell you a thing about the benefits/costs between the different datastructures that the blockchain could maintain consensus over, or how to write the transactions to modify the datastructures, or how many goals each transaction should accomplish.
A physicist can explain about torque, pressure, strain, and stress in columns, and can explain why a bridge stays standing, but he has no idea how to operate the tools involved in constructing a bridge.

[zack]

I updated the code with the new slasher tx type.
lines 81-99, 286-297

Keep telling me of bugs, I will fix them.

[zack]

I am very emotionally distressed.
The new patch does not fix the bug. Neither of our methods are secure at all.
I think I am about to produce a proof that a secure prediction market on a blockchain is impossible.

Lets say Bob is a votecoin holder, and he votes on the outcome of a PM. His vote is still encrypted.
Alice wants to learn proof of how Bob voted, so that she can create a punishment transaction and steal all his money.

This punishment transaction has the same information in it that is revealed when in Bob's reveal transaction.

If Alice was a mining pool operator, she could ignore Bob's reveal transaction, and use it's contents to produce a punishment transaction and steal from Bob.

[koeppelmann]

I thought about the problem and I think I have a simple and good solution.

The first vote of a voting period is done by signing a hash of the vote and submitting it into the blockchain.

1. You take your votes (Ballot) and add a random string
2. take a hash value
3. sign this value with your private key
4. submit it to the blockchain

The important part now is, that no the vote can be changed just by providing the votes + random string that lead to the hash value.

This solution would achieve the mail goal:
- voter would loose control over their vote if they reveal it early
and in addition no private key publication what be needed.

What do you think?

[koeppelmann]

I am very emotionally distressed.
The new patch does not fix the bug. Neither of our methods are secure at all.
I think I am about to produce a proof that a secure prediction market on a blockchain is impossible.

I am sure - there are solutions for all these problems and I appreciate your work.

[zack]

I thought about the problem and I think I have a simple and good solution.

The first vote of a voting period is done by signing a hash of the vote and submitting it into the blockchain.

1. You take your votes (Ballot) and add a random string
2. take a hash value
3. sign this value with your private key
4. submit it to the blockchain

The important part now is, that no the vote can be changed just by providing the votes + random string that lead to the hash value.

This solution would achieve the mail goal:
- voter would loose control over their vote if they reveal it early
and in addition no private key publication what be needed.

What do you think?

Your suggestion is what I am already doing. I think it is the simplest and best way.
(but this still doesn't solve the separate problem that I am emotionally distressed about.)

[koeppelmann]

The important part now is, that no the vote can be changed just by providing the votes + random string that lead to the hash value.

I was not aware that this part is part of your solution.

Lets say Bob is a votecoin holder, and he votes on the outcome of a PM. His vote is still encrypted hashed .
Alice wants to learn proof of how Bob voted, so that she can create a punishment transaction and steal all his money.

This punishment transaction has the same information in it that is revealed when in Bob's reveal transaction.

If Alice was a mining pool operator, she could ignore Bob's reveal transaction, and use it's contents to produce a punishment transaction and steal from Bob.

I don't get the problem. All Bob has to reveal is his "vote+nonce"=vn that has created the hash he submitted earlier. If someone get access (before the voting period is over)to this "vn" he could change the vote (but not transfer votecoin). If he submits "vn" after the voting period (as he should) nobody gets access with "vn" to anything.

After all votes are revealed the RBCD (reputation based coin distribution) is done that assigns to all votecoin addresses a new value.

I don't understand where Alice (as a miner) could cheat in this process?

[zack]

With your method, if there was a fork in the blockchain, the miner who made the longer branch would be able to control all the votecoins from everyone who voted on the shorter branch. That single miner would likely have over 51% of votecoins, and he would cheat.

There should be a punishment for revealing your hash ahead of time.
Revealing you hash ahead of time makes it easy to collude. So we need a punishment for people who do it.
That is why I remove all the votecoins from people who reveal their hash ahead of time.

[koeppelmann]

With your method, if there was a fork in the blockchain, the miner who made the longer branch would be able to control all the votecoins from everyone who voted on the shorter branch. That single miner would likely have over 51% of votecoins, and he would cheat.

No - all he could do is to change the votes for a single ballot. And he even can not do this because it could be separated by time. Lets say hashed votes could be submitted until 01.01.2015. Then the revealing phase starts at 03.01.2015. If the miner not gets the "vn" values / revealed votes all he could do is change votes in a blockchain older than 24h and try to overtake a blockchain that is more then 24h ahead - he could only do it if he head way more then 51% hashrate and even then he did not control any votecoins for the next ballot (because he can not sign new votes). Thus this blockchain would only have votes from the votecoins the attacker controlls.

With your method, if there was a fork in the blockchain, the miner who made the longer branch would be able to control all the votecoins from everyone who voted on the shorter branch. That single miner would likely have over 51% of votecoins, and he would cheat.

There should be a punishment for revealing your hash ahead of time.
Revealing you hash ahead of time makes it easy to collude. So we need a punishment for people who do it.
That is why I remove all the votecoins from people who reveal their hash ahead of time.

Losing control over this vote on this specific ballot is enough punishment to avoid collusion.