Quote from: magician on March 29, 2014, 01:13:53 AM

Quote from: phm on March 28, 2014, 11:57:42 PM

Quote from: magician on March 28, 2014, 02:51:07 AM

Having heard the community's concerns about block hashes being prone to manipulation, we have decided not to use block hashes to resolve bets. Rather, we will be using New York Lottery Quick Draw numbers to resolve bets.

New York Lottery Quick Draw

Quick Draw numbers are drawn every four minutes, every day of the week. The numbers are published online shortly after they are drawn. The drawing selects 20 numbers randomly from a pool of numbers 1 through 80, without replacement. In the newest version of the Chancecoin protocol, a bet seen in the blockchain will be resolved with the next available set of Quick Draw numbers. We use combinadics to convert these numbers to a random uniform variable, and use it to resolve the bet.

We have more updates coming this weekend.

I think that with this solution miners will still be able to manipulate the results with the following algorithm:

1. make a bet
2. mine a block
3. if current set of Quick Draw numbers makes me a winner then publish block
4. wait for the next set of Quick Draw numbers
5. goto 2

Of course someone else may mine the block in the meantime, but a large pool with 30-40% hashrate of the network will make the results considerably unfair. Pool with 90% hashrate will be able to win almost every time. How will you prevent that?

The bet is resolved based on the first set of NY Lottery Quick Draw numbers that are published strictly after the block is mined, so it is not possible to game the system by waiting for favorable lottery numbers. Thanks for the question! This is an important clarification I should have made earlier.

Not sure if you know this, but timestamps in blockchain are prone to limited manipulation, rules of validating them are quite fuzzy. "A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours". So in fact nothing prevents miner from sending the block with timestamp few minutes in the past or in the future, timestamps in consecutive blocks don't have to always increase. How will you enforce such rule if you don't really know the real time when given block was mined?