1. The numbers are taken from the first NY lottery immediately after the block that contains the transaction. Does this rely on perfect time synchronisation, with the timestamp put into the block being the correct time? What happens if a block is orphaned and the transaction moves into another block that is subject to a different set of NY lottery results?
2. The technical specifications and the code appear to differ:
- Spec says final variable is (rA + rB) %1", but the code says %2
- Spec says Ra is the sum of (number i) over each i in 1..20, but the code says (number-1 i)
- The code has a factor of 100; is this represented in the specifications? Code is: roll1 = n/(N-1)*100
Am I reading this wrong (quite likely, actually...); or which one is correct?
3. Do you have formal proof that rA is a standard uniform random variable (assuming the numbers from the NY lottery itself are random)?
Shameless bump! Did the dev (or anyone) get a chance to take a look at these questions yet?
we need the dev team show up to solve the problem and tell us the process of this project.
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.
Magician