It looks like you're new here. If you want to get involved, click one of these buttons!

- 17.3K All Categories
- 9.5K Mining
- 573 Pool Discussion
- 374 Promotional
- 1.4K General Project Discussion (non-technical)
- 485 Education
- 810 Protocol and Client discussion
- 169 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 303 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 359 Solidity
- 664 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 470 Geth - Go Implementation
- 242 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 170 Meetups
- 40 Other Events
- 225 Jobs & Skills
- 281 Press and Articles
- 75 Audio/Video
- 296 Ether Sale
- 1.2K Other Languages
- 96 Chinese
- 255 German
- 33 Italian
- 111 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 184 Russian
- 230 Spanish
- 47 Turkish
- 125 Watercooler

kitten
Member Posts: **6** ✭

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.

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

514✭✭✭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.

514✭✭✭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