The main problem is really with the selection process. I'm actually in the process of possibly slightly altering the algorithm for picking the winner. The important thing is that I do it at least a few days before the draw of course. I hate changing it though, but I think it needs to be done. It does add a *little* more complication to the calculations. The problem with known ticket hashes prior to the draw is people could do frequency analysis of the tx hashes. They could see if by random chance some combinations of digits are not as frequent amongst the hashes. Then get tickets with those more rare combinations. It would be pretty tricky to do but I guess as the money goes up, people will try to get any advantage they can no matter how slim. I'm sure it would be pretty hard to do as the tx's go up there is a lot of tx's to analyze. They would also have to wait till the very end so it would be quite the feat for a very very tiny advantage.
So, to make it pretty much impossible to do any analysis I was thinking of rehashing ALL tx's!! It would make it harder for others to check the results casually but I'd release a txt file with contents something similar to this for every draw:
720b8516a286a6588ae636c16e8c550366931620623050b34d9dc0e3856c945c -> c533da9261c21db0bf12d9e6061b10f7652db674a6a0007ec9dfa1b9fe15e219 -
99a38da78eee8132ac2be9d2cbef69df7d81c2adf78423d9c2ee21819f70772d -> 6a4e06c1a1d4bcfd21ddc0bd060a09a92c58334c3aca067106c515beaf7b7bcd -
.520000
b46482a6f375297e0c2dc74603fb0d455912a6748ca65efd8130a96211e9f36a -> be7baa0fc748e3c44e5cc26f9165ed15fc7da62db3443a6cefbf0cf4986575d8 -
.150000
5ae95246eabb8fb7229db1fcc3aebe258d1a68aae21b4747ecf992a946e902df -> 093c9522b279bf0653304eb33cc9e6b1599199bc413dd647cf99fe604f6d4561 -
9120dec5bfe999743ba3b44d7828dd76196a82cca3486497b74e37fd6a8500d0 -> 198cb6b9ebd194bd79f19fac8b153808b385024929c1cffd320819be4983fa38 -
367b185f2af5d60a72469839d66e07f4c0145a646c48bc6fb2a8304096865266 -> a9a52a45e7252e7e0238f4dc7cdf0f7d6d2ed5a3d4c70e55f9960c103cf1d4a1 -
985ec0242ba5ca7d8af982644eaa056d8e1af8de3bb5c056aa39ae3ff358ab8b -> 7ea9843c17026e2c7681cd1185b4edc32e51aecc4414174cf5082bbfd8aa8b58 -
5b2b7fe513b77bf333b3e202f370699cb914526cdeb49f14b0df78ae16608926 -> 97cfa87250deab7f2d821fc26a7eadb561428f28b1540af51baa22867111994f -
5dc34f516c14115ce10051f3f73f92892ce704083d22832e4d155f6c87c3abc6 -> 2312b230ae328384202d7b65b7bac25d036a5bd0a86b805c56cffbdf618eac35 -
15ce39e11aecf0a402d2da8bd829cec6505b5fbad023ba8021f663df1d077716 -> 6bdd36da928e20617baa139e0ee6b1c096d891cad8cb5fa2997abc9c7eb4c8cf -
b67003391d72709ce1b8cf159a7c38e69ce09cc64f8c509fb898dd20af967237 -> 09a63f04c4775eb5976d68df695f679667a59cb68bc07afa889f8539bc2591df -
1328e3d465132c4b012d44e5d28bff76e6f31566dc87f1e59c593bc94b73da39 -> e767f076d208cfdcf388bc0e7edd06367d95c1dc9a08c87bbd6848ecf4fb23bc -
7514500e9d536146575055de0f6ef9675d4b829f3329a8e4a2c20cc4bdcd09dd -> 3550fb0a84247be1656d46b23874ca357827e0423cba2e58f56062c6a4bb919a -
bba5ee2812dbb43da4014f27c83a63488dcc2305ece1f7412b8646911cc9ba67 -> 8c023c452e1cc5207eb8de8d3af3b132aee553adc4098d4767a7543125025ac5 -
111dc53308d19a5a74a0537165a7f3a002269a5049d590f7a664909c3c07263f -> 5518205694948464143c4b30959ce36b8f2dd431502e7bbbbd9b361742a683d3 -
07f664b68ec82238a3465ce570215eb001ef795f906abe67e8f11e7d4fa1e338 -> eec308f8df80ad59dff7c9902acde257feb9efb6f1f499838d1a08ef06c518ec -
470daaedb373af852030e71eace9cfffe51f2e38fb085f08d42098e627d58b82 -> e71dd2934da9c61b045fb7a1ed5213ad6cdb8533191297632ee0287a3bca8bcc -
ba5e9c70817ffe8148d99774b4dc777dab5949727c8f7a73e49624d662501f02 -> 8d07912630e1ba0b96fe72d0bcfccf906498b6b9f12bfbb4aff55558de673535 -
9629cfd252f00c0de1063874e46ed3f574a0732425ae28e2776502da8613b017 -> a64fd00c9f22b7ee992ee6949f4e0ae2c1ff658ff04eb8c4fe3aad5612c9ee77 -
9e37ee5af0fc5d0c20cf1f7e93a579ff149a29bcdbc92da9181bde88074170c5 -> b2919892d4aca12f2269bf4401a86bb6abfd2487ebabd9402cf3e5ed1996f5b5 -
4.260000
bf9f0c11fc2f1ff82fa5f4b4769169c619b237dd62e93fbcdf2e091abc1d29ec -> 233c01ffba150ad136ee4d589d03ea9f82067e6bce581e6a404d200f0fddb463 -
.250000
f08f16cb4acac8e334d4e99155085cd5f03730936b06e1ea68c2d1fd0ece18d2 -> dba501b70e179611a39515b2c7c32882a9ecc56154444f351994420c616ce3ab -
.350000
59e8d1b6c351cb4d2a738f246a74f373f5245bdf0e485e622d4411a048ac8802 -> 52d8914b1aea413a6ecae1108cb6653bdf38799d3a152bfc15a9de64f0fbfaf5 -
.250000
This would show the original tx hash and the new hash that's used for picking the winner.
Doing this makes it impossible for anyone to analyze tx's since the hashes can't be know till it's over! I'll probably end up hashing the tx's with the winning picks added. THEN use the new hashes to find the winner.
It fits in with BitLotto's goal of being cheat proof and still remains transparent.
Unless of course someone can think of something more simple and still cheat-proof?