A source of entropy

I've been thinking about how to make a trivial casino contract (entropy has other uses as well, e.g. flip a coin to determine who in the marriage contract gets the car) in lieu of entropy, and came up with this (2 block process):

1st block: Make a commitment.
2nd block: You reveal the committed value, which is xor'd with every other committed value to produce a "random" value.

It's imperfect and can be gamed, but ought to work for most situations where at least two parties are not cooperating. Even then, however, it's not true entropy, it's more like a game of paper scissors rock.

However, just like paper scissors rock, the entropy of the resulting random value will be at least the maximum entropy of all of it's inputs. i.e. we only need one person to be playing randomly for it to work.

Comments

  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    edited March 2014
    I think that would work..

    Here is a thread about getting random numbers https://forum.ethereum.org/discussion/comment/2758/

    Using block hashes is mentioned, but i has serious problems; they suffer from the miner collusion problem i mentioned. Basically the bet is 'run again' every created block. So if a colluding miner doesnt like the result of the bet of a block he found, he can just not report it.

    The extra income from failing to report a block he expects is av{E}=av{r-R-h|=Av{r}-R-h >0, where R is the reward for a block, h the block reward he is missing. (Av{x} being averages, R and h are known given the winning block the attacker may withhold-or-not)

    Although in relative terms the typical result comes closer and closer to the mean, in absolute terms, they do not. For instance for N players have p probabilty of winning, the standard deviation of winners for large N is proportional to sqrt(N); always increasing. So eventually the expectation would exceed block rewards.

    Worse, though, colluders may try get eyes everywhere on the network, and if someone else comes up with a block and publishes it, he might look at the outcome of the bets on that block. If the competing block is in the end worse,(including missing out on the block reward) the attacker can still put his block on the blockchain and hope it is accepted. The prospect of being able to have a shot at getting the block in anyway also increases the threshhold to not publishing immediately.

    Thought of ways to get around it, like miners revealing H(R) when they win a block and revealing it later. But then the worst they can be punished for failing to deliver the secret random number R is just losing the block reward. It moves the problem, although it does avoid all the 'single-block-forks' that essentially would be the result of last-minute-try-the-block-anyway people.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    In the other thread i linked @kitten linked this: https://crypto.stackexchange.com/questions/1858/is-there-some-way-to-generate-a-non-predictable-random-number-in-a-decentralised

    The last one indicates an attack on your scheme; given two parties committing the second one to go can commit H(R2)=H(R1) he doesnt know the R1, but he simply waits for it and publishes the R2=R1 when the other guy goes, so that xor(R1,R2)=xor(R1,R1)=0
Sign In or Register to comment.