Quote from: Kyune on April 26, 2014, 07:19:10 AM

Quote from: notsoshifty on April 14, 2014, 10:57:46 AM

Quote from: magician on April 13, 2014, 04:36:10 PM

1. This does rely on reasonable time synchronization. If people are worried about timestamp cheating, we can always increase the verification time, but there's a tradeoff there. If a block is orphaned and a transaction moves into another block, the bet will be resolved based on the new block.
2. The %2 was a bug. I just released version 1.3 to fix that, and the Windows client will be updated shortly. I also updated the technical specification to reflect what actually happens in the code. (number i) was a typo, and I had forgotten to mention the factor of 100 is simply to put the standard random uniform variable into percentage terms (since Chancecoin saves the chance of winning as a percentage as well).
3. I can write up the formal proof once the bitcoinj wallet gets off the ground. I apologize for taking a while to answer questions recently. Venetian and I have been pounding the code treadmill pretty hard with this new wallet software.

Thanks a lot. Makes sense.
On the time sync point: where is the current verification time defined, or at the moment is it zero? Do the bitcoin spec / software / major minors define anywhere a maximum time skew that would be allowed before a block is rejected? (I've not checked the bitcoin blockchain, but in alt coins I've certainly seen blocks appear out of timestamp order, especially during the instamine phase, presumably due to lack of time sync in the miner). Is there a guaranteed delay in announcing the lottery numbers? Would it be possible for a rogue miner to do something like:
- Normal case: mine without an Chancecoin transaction, and with the correct timestamp
- As soon as a lottery result is made available, and for the next 10 seconds, mine with a winning Chancecoin transaction (might need a few attempts to get a suitable transaction ID), and with the timestamp out by 10 seconds
- After 10 seconds, go back to the normal case (no Chancecoin transaction; correct timestamp)
If that is a possibility, could you also include the block ID into the mix (like transaction ID is now) to prevent this behaviour, and would that help?

I did not see a response from the devs to the above. It does seem within the realm of possibility that timestamp mismatches and reliance on an external data source could be exploited by sophisticated actors to tilt the odds in their favor, particularly by harnessing mining power. Is Chancecoin provably fair...for the house?

But to exploit this if I understand correctly, you must attack the whole Bitcoin network which is not worth it at all.
So it is just impossible.