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.
Step 3 is where the issue occurs. The last party to submit their value has control over the output. Any complex calculations can easily be passed off as network lag. One solution I can think of is to pass the values round in a circle, one by one. This would require each party to share their value before they have seen all other values. At the end each party would share their calculated values to verify they match. Probably other solutions as well.
Amazing solution, didn’t arrive to that one, I was thinking just making a timing constraint to reveal the number that would make the precaculation practically imposible, but the commitment schmeme is waaaay more elegant.
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
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)
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!
Step 3 is where the issue occurs. The last party to submit their value has control over the output. Any complex calculations can easily be passed off as network lag. One solution I can think of is to pass the values round in a circle, one by one. This would require each party to share their value before they have seen all other values. At the end each party would share their calculated values to verify they match. Probably other solutions as well.
Most remote coin tossing schemes incorporate commitment systems for this reason.
https://en.wikipedia.org/wiki/Commitment_scheme
Amazing solution, didn’t arrive to that one, I was thinking just making a timing constraint to reveal the number that would make the precaculation practically imposible, but the commitment schmeme is waaaay more elegant.
Yes, that makes a lot more sense.
How does the group reach consensus on N?
Polling, probably - if the majority of group members are bad actors you’re fucked.
Are we talking about American politics again?
Do we ever talk about anything else?
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