# start using reproducible random numbers #98

Merged
merged 4 commits into from Feb 5, 2019

## Conversation

Projects
None yet
4 participants
Owner

### jeffkaufman commented Feb 4, 2019 • edited

 Currently we have Travis running random.random() to determine if someone has won. This of course gives different values each time you run it. This is basically fine, but it would be better to use a hash of something that (a) we all can verify and (b) we can't predict. Then we don't have to trust Travis or worry about people re-running Travis builds. This PR switches us to using the hash of the merge commit as our source of randomness. As a sanity check on the math I generated the random numbers corresponding to the 194 commits we have on master, to see that it really does give the full range of values: https://docs.google.com/spreadsheets/d/1PwRT8q5OdjWsZsGTHwZSlw4zCjy2yaUvKi0UX--7Wtk/edit#gid=0
``` start using reproducible random numbers ```
```Currently we have Travis running random.random() to determine if someone has won.  This of course gives different values each time you run it.  This is basically fine, but it would be better to use a hash of something that (a) we all can verify and (b) we can't predict.  Then we don't have to trust Travis or worry about people re-running Travis builds.

This PR switches us to using the hash of the merge commit as our source of randomness.  We only get one of these, so this depends on the fix in #97.```
``` 95ad762 ```

### pavellishin reviewed Feb 4, 2019

 @@ -94,9 +93,33 @@ def determine_if_mergeable(pr): def determine_if_winner(): print_points() # Pick a winner at random with a single random number. We divide the number

#### pavellishin Feb 4, 2019

Collaborator

#97 changes leaked in.

#### jeffkaufman Feb 4, 2019

Author Owner

The #97 changes are here intentionally (see PR description). Without the #97 change we call `random()` multiple times, but `util.random()` only returns a single random number at any given master commit.

#### jeffkaufman Feb 4, 2019

Author Owner

We can wait to review this until #97 is merged, though, if you like.

#### pavellishin Feb 4, 2019

Collaborator

I almost want to throw caution to the wind; this isn't work, this is a game! But yeah, we probably should :P

#### jeffkaufman Feb 4, 2019

Author Owner

No problem!

(This isn't really a caution-to-the-wind sort of game...)

Collaborator

### pavellishin commented Feb 4, 2019

 We can't reasonably predict this because we can't control Github's merge timestamp, right?

### jeffkaufman added some commits Feb 4, 2019

``` Merge branch 'unbiased-random' into consistent-random ```
``` 57c9acb ```
``` tweak illustration ```
``` 16ba7b5 ```
Owner Author

### jeffkaufman commented Feb 4, 2019

 We can't reasonably predict this because we can't control Github's merge timestamp, right? Right, otherwise this wouldn't work.

Merged

Collaborator

### tnelling commented Feb 4, 2019

 Looks good but let's merge #97 first.
``` Merge branch 'master' into consistent-random ```
``` 1d6c32e ```
Owner Author

### jeffkaufman commented Feb 4, 2019 • edited

 @tnelling @csvoss @pavellishin ready for review, now that #97 is in

validate.py

Contributor

### csvoss left a comment

 Might be vulnerable to timing attacks?

### csvoss merged commit `1d6c32e` into master Feb 5, 2019 1 check passed

#### 1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

### csvoss added a commit that referenced this pull request Feb 5, 2019

``` Merge pull request #98 from jeffkaufman/consistent-random ```
`start using reproducible random numbers`
``` 0003490 ```
Owner Author

### jeffkaufman commented Feb 5, 2019

 Congratulations @csvoss!
Collaborator

### tnelling commented Feb 5, 2019

 Was that actually a timing attack, or coincidence?
Contributor

### csvoss commented Feb 5, 2019

 Definitely a timing attack. :)
Collaborator

### tnelling commented Feb 5, 2019

 Care to explain? Was "We can't reasonably predict this because we can't control Github's merge timestamp, right?" incorrect?

Closed

Owner Author

### jeffkaufman commented Feb 5, 2019

 Was "We can't reasonably predict this because we can't control Github's merge timestamp, right?" incorrect? Totally incorrect: the timestamp just goes to the second. Merging to a specific second seems pretty doable.
Owner Author

### jeffkaufman commented Feb 5, 2019

 The bigger problem is I can't figure out how @csvoss avoided having github sign the commit, which makes the hash unpredictable.
Contributor

### csvoss commented Feb 5, 2019 • edited

 edit: explanation moved to #100

Closed