Quote
If a miner has a sufficient amount of hashing power, and a sufficient amount of pevpot tickets and the pevpot prize pot is big enough it could theoretically be advantegous for a miner to discard a valid bitcoin block if that block would to them losing the pevpot draw. If this theoretical attack looks like it could be a concer, the most obvious fix would be to change verification to be an extremely time-consuming process (e.g. bcrypt the block hash with millions of iterations) so that it would be infeasible for a miner to check if their block won or not (without getting orphaned). If you have any ideas for this, we'd love to hear your input on the forum.
I bolded some typos.
I'm trying to think of a method that prevents the miner from instantly knowing whether his newly solved block results in him winning the lottery or not, without also making the verification of the provable fairness overly burdensome for the players. The bcrypt idea above has the problem that everyone attempting to verify the result also has to run millions of iterations of bcrypt.
I came up with this:
You know how it's really hard to go from a Bitcoin public key to a Bitcoin private key (like *really* hard), but very quick and easy to go the other way... Could we use the same idea but made easier to solve this problem?
Instead of using the secp256k1 curve that Bitcoin uses, use a 48 bit curve or some such, and treat the last 48 bits of the miner's block hash as the public key. Then the proof-of-work to determine the winner involves searching for the corresponding 48 bit private key. Once found, append the private key to the block hash, hash the result, and that's your 256 bit value for deciding who won.
The advantage of this method over the million-bcrypts method is that it takes no work for anyone to verify that the private key matches the public key, but it takes a lot of work to go the other way.
Oh, but it has two problems:
1) the search is easily parallelized - so someone with a lot of hardware (a miner, say) could search quicker than others
2) I'm not sure that there's any guarantee that there's only one private key for each public key
I wonder if it's possible to find a solution which isn't able to be parallelised, takes a long time to solve, but no time to verify.
http://crypto.stackexchange.com/a/9331 looks promising. It gives us:
* slow for the miner to compute
* quick for the users to verify
* not possible to parallelize
but with the disadvantage of the pevpot site having to keep a secret until after the draw, and being able to cheat (by removing the slowness) if it colludes with a miner
