- Decide on a random N and what tails (even) and heads (uneven) mean.
- Each party generates a random number
- Combine the numbers with a conmutative operation of some sort, the harder the operation the better.
- Take the hash N times. (Can be done independently by each participant)
(4.5) optional: for extra robustness, do some hard-to-calculate transformations to the result of 4. (Can be done independently by each party)
- The final result is either uneven or even === coin toss. (0 will be treathed as even*.*)
This is not infalibe, one party could get all the numbers a precalculate a answer to get a specific result but they will need to randomly try numbers. adding some timing constrains, using big numbers and hard operations would make that sort of attack not really practicable.
Nice question, had fun thinking about it!
Not very important, even if generated by a single actor N has not such a big importance. If I were implementing something like this I'd just probably make it -hardcoded-.
If you reaaaallyyyy want to decide on a N on the fly, I'd put a restricction (a<Nx<b) make each participant generate a Nx and then sum then all, -multiply'em If you wanna be hardcore- But I'd be tricky to get it right, for example a party might be able to consistently make N whatever the max value of N is by making their Nx very big -Which, well, I don't really know how it would benefit that party and how would they exploit it-. Maybe using a operation like a XOR on the Nx would be robust enough, and would mitigate the kind of attack that I described above
Tl;dr: you can just have a random party generate it.