Why is ethereum not using threshold signatures like dfinity for randomness? What's the drawback? So Ethereum goes for RANDAO. The disadvantage with RANDAO is that the last validator in the commit-reveal scheme is able to hold his contributed value back and thereby influence the random outcome. Ethereum is trying to overcome this by using verifiable delay functions.


Why all that hassle?
Why not just go for threshold signatures like Dfinity?
What's the drawback?


Some link to a statement from Vitalik Buterin on this would be highly appreciated. Otherwise, if you can explain it it's also fine.
This post is a little old considering the current conversations going on about the various approaches to generate secure, safe, live and unbiased randomness in Ethereum 2.0. However for a better update on the ongoing conversations, please let me share the latest progress in this discussion.
Ethereum 2.0 is proposing a combination of RANDAO ( biased entropy) + VDF (unbiased entropy) now as a choice for the source of randomness in the beacon chain. Justin Drake has written the following construction in the Ethereum Research forum.

Assume a global clock and split time into contiguous 8-second blocks and 128-slot epochs. Each epoch produces 32 bytes of (biasable) entropy to which correspond 32 bytes of (unbiasable) randomness In a recursive fashion, the beacon chain proposers of epoch (one per slot) are sampled using past randomness for some suitable constant.

A few researchers in the discussion forum have opined that it will have the following advantages over the threshold signature scheme of DFNITY.

The threshold relay scheme from DFNITY stands out as not being
biasable. Unfortunately, the beacon can stall if even a minority (e.g.
15% 1) of honest players go offline.
As indicated by @denett this does not work because the sampling process will weaken your honesty assumption. (Dfinity’s sampling weakens the global 2/3 honesty to 1/2 local honesty.) Sampling is required because the Distributed Key Generation (DKG) scales quadratically with the number of participants, and in practice you can’t get much more than 1,000 participants.
Another thing to consider is that there are two ways in which the
Dfinity beacon can fail. Citing the whitepaper: “We treat the two
failures (predicting and aborting) equally”. By improving liveness you
make the readomness beacon easier to predict.
Finally, the RANDAO + VDF approach allows for arbitrarily low liveness
assumptions. (For example, we could have a 1% liveness assumption by
making the RANDAO epoch longer.)

I had relentless participated in the Starkware Veedo Streak hackathon and used the VDF based Randomness through Beacon contracts deployed in TestNet and MainNet. It looks like the VDF approach is gaining traction in the Ethereum Research community.