That's a good solution. I'm curious to know if you have such a function (easy to verify) in mind.
The best I have for now is just "bcrypt with millions of iterations". The nice thing about this, is you can't parallelize it, which means you can make a very good estimate of the amount of time it would take to solve. Even if it took people ~30 minutes to solve, it'd be a bit inconvenient to verify, but not show-stoppingly so.
you don't say anything about how many confirmations a deposit needs to be included in the draw.
Thanks, I'll add this. As long as it gets confirmed on or before the draw hash, it counts. If it doesn't get confirmed by the draw hash, it'll just be part of the next draw. (I will reuse the lottery address, specifically for this reason)
In the case of reorgs, the hash is used from the chain with the most work. No payments are automatic (the lottery address is part of my cold wallet) and won't be sent immediately (I want to give people time to verify the draw outcome before I sent payment) so it won't really be an issue. Worst case is someone will think they won, then there will be a re-org and a different winner is picked =)
(I believe this is really the only way to do it provably fairly, otherwise if there was a block race it's not possible for me to prove I saw X before Y)