Another approach is to have several parties (perhaps every block creator) contribute a number. Then we concatenate the numbers and feed them through a delay fun

Another approach is to have several parties (perhaps every block creator) contribute a number. Then we concatenate the numbers and feed them through a delay function, which should take everybody a certain minimum amount of time to compute, regardless of computational power. The result of this function becomes the random seed for some future block. An attacker cannot predict how their number will affect the result, since they would need to compute the delay function first. By the time they finish the computation, they'll have missed the window of opportunity to contribute a number. (They could add their number on a very old fork, but other clients would not accept forks beyond a certain age. This is important anyway to prevent stake-bleeding attacks.) A obvious candidate for a delay function is an iterated hash function like sha3^10000. A few researchers are looking into "verifiable" delay functions [1], so that not every client has to do the computation; most clients can download the result along with an easily-verified proof (perhaps using a SNARK) that the result is correct. Besides saving some computational resources, this would help new nodes catch up to the network quickly, without needing to compute all the historical seeds. [1] https://www.youtube.com/watch?v=qUoagL7OZ1k https://www.youtube.com/watch?v=qUoagL7OZ1k