You could go so far as to have every ticket purchase include its own secret. Once the purchase window is over, everyone reveals their secrets. The hash of everyones secrets becomes the winning number. Because no valid transactions should ever be excluded from the block-chain for more than 1 or 2 rounds of the BOD we can safely assume that no one could know the random number generated in the end.
Yes, @logxing and I had a discussion about a similar solution this afternoon.
I have an idea and today I had discussed it with hackfisher.
Here is it:
1.Every Tx has a parameter which is a random public key(e.g. ECDSA).
2.Miner will pack these Txs and generate a new block(e.g. at the 500th block).
3.When block 505 were generated, the DAC client will send the private key generated in step 1 automatically.(505 is just for safe, make sure not to send private key too early)
4.These private keys will also be pack in block 506-510.
4.When block 511 were generated, new private key for block 500 will not be accepted any more.These private keys for block 500(recorded in block 506-510) will be the seeds of the random number generator, using for determine the result of block 500.
Thus, when miner generate a block, they can not predict the result by select Tx, because they don't know the seeds(private keys).The result of block 500 is related with Txs in block 500 and the private key for block 500 recorded in block 506-510(generally ,not all private keys of Txs in block 500).
How about that? More details need further discuss.
Each user generate a random public_key together with ticket purchase, and after the ticket transactions are valid, user then publish their private key relate to the pub_key. DAC (miners?) use this private key to generate random numbers. I think This approach is quite similar to FreeTrade's meaning of provable distributed. Random number generated in this way is more reliable, I think, even though it introduce more complicate design:
1. How to select the pub_keys from distributed entities' transactions in this block, we could not identify entity behind address?
2. How to collect enough/required private keys before deadline?
The simplest way would be to use all the private keys already received before deadline, but the transactions to publish this private keys also need to be mined, in another word, has the chance to be filtered by bad miners.