Haven't given up yet. Is there a reason this wouldn't reliably get random numbers into a decentralized network?
3 forgers at once, first 3 from the list of next forgers in line to forge.
A picks a random number, signs it, and sends to B
B picks random number, signs it, and sends to C
C picks random number, signs it, and sends to A
No machine can pick a number based upon the numbers picked by the other two machines because they don't know them all.
All forgers wait until the other machines have picked a number and have heard from the other machines that everyone is holding onto their digital signature for some data they don't have. All every forgers knows is the signature of the machine that passed it data.
Now they send their actual data to the next machine, that machine double checks the signature against the data and sees that yes, this is the data that was signed by the last machine.
They sign that data themselves and broadcast it to the network. Now all forgers know that A has signed that it generated this random number as well as the random number and they have verification from B that B is saying A is telling the truth.
Now every block has a truly unique random number attached to it.
If either A or B are found to not match up, you'd probably want to flag them as suspected liars or manipulators, it could be either one that is lying about the other one, most likely one of them is being honest but there is no way to tell which one. If they are found to be lying, ditch the random numbers that are disputed.
Every block sum the last 10 minutes worth of random numbers along with the account balances from 1440 blocks ago (or much sooner with this scheme?) and use that to determine who will forge next.
Please attack it!
Looks like ByteCoin agrees with me, after writing this up I did some poking around and something like this should indeed be a way to generate an agreed upon random numbers within a decentralized environment:
http://crypto.stackexchange.com/questions/1858/is-there-some-way-to-generate-a-non-predictable-random-number-in-a-decentralisedEdit: actually no reason A should only send his signed copy of the data to only B, send it to both B and C.
B should send it's signed copy of the data to A and C, and C to A and B.
