P2P gaming should use this too: everyone makes their moves, send a hash of the moves, then send their moves. It eliminates cheating during the final move exchange, where someone could change their moves after seeing other players moves.

It's interesting that using a PoW blockchain such as Bitcoin as a random beacon is another way of implementing a pre-commitment. Since blocks are created upon another, and have to meet PoW difficulty requirements, miners are effectively pre-committing to which class of random value is the next beacon, while the economics (and provably difficulty of PoW), makes it expensive for them to manipulate future random values by discarding valid PoW solutions with undesired beacon values. Basically for every bit in the PoW beacon value that you want to fix, you have to throw away half of the potential block solutions even if you have 100% of hashpower: expensive!

Related: another clever technique that can build on any random beacon is to use a long hash chain to actually determine the final beacon value. Zcash actually used this for one of their trusted setups. Basically, they computed SHA256(x) iterated billions of times, a serial computation that took something like a week of solid computing, using a particular Bitcoin block hash as the initial value. There's no way miners could influence this, as there was no way that they could do the serial computation fast enough to know what actual beacon value they were creating.

Let's say you are organizing a sports event. In a knockout tournament it is really advantageous if you could only face weaker teams, until the final game where you face a team which had to fight all the other strong teams instead.

Two months prior to the event you number each initial spot in the bracket, and you assign a number to each team - sort them alphabetically or something, it doesn't really matter. You tell everyone that assignment will be done by shuffling using a well-known PRNG, and you'll take the beacon value one month from the event as seed.

The T minus 1 month point is reached, you download the beacon value, feed it into the PRNG, and shuffle the teams to get the final bracket. The algorithm and all inputs except the randomness was fixed in advance, so you cannot manipulate that. You have committed to the seed without knowing it, so you could not have possibly manipulated the seed either.

Everyone can verify this, so everyone will agree that the drawing was done fairly.

I think you are meant to commit to using the value of the beacon at a future point in time, e.g. when you're preregistering your trial methodology.

The NIST site has a few, but basically it's useful any time you need to randomly select things and prove your selection is really random. The idea is you commit to using a specific future beacon value in a particular way to do your random selection, so you can't game either your random value or the process to get the selection results you want.

One example the paper gives is auditing an election by looking at a random sample of polling sites. Before the election, the government commits to using a specified algorithm to select polling sites to audit, with the random input coming from the first beacon value on the day after the election. This verifies prior to the election that the auditing will be random without revealing what polling sites will be audited (in fact there is no way for anyone to know that prior to the beacon value being published). The government can also use multiple independent beacons. Assuming not all the parties are colluding, this does a pretty good job demonstrating the auditing is random.

https://csrc.nist.gov/CSRC/media/Presentations/usages-of-pub... has some.

On the subject of verifiable fair betting. in the early 1900's the mob "numbers game" which in my understanding is a sort of lottery, used low order digits from the closing price of well known stocks to pick their numbers.

People could trust the the numbers were fair because they were generated and published outside the domain of the person running the game, it would be very hard to fix the cent values generated by stock activity and the same numbers were published in all the newspapers.

Someone who knew or guessed that you were doing it could find your key very quickly by trying out every beacon value in the time range your key was generated in

Many exploited systems have effectively done this. A random number generator is seeded with something like "PID + timestamp + milliseconds since system startup." But all these numbers cluster in a small range, so it's practical to test all of them and figure out the seed.

similar things to if you were to use the top row of your keyboard as a password