Hacker News new | ask | show | jobs
by GuthL 2496 days ago
Secure randomness requires unpredictability, unstoppability and unbiasable. If you are flipping coin based on bitcoin randomness, the block proposer has an advantage over you. It is not technical secure randomness. That's why Ethereum 2.0 is planning on using a RANDAO + VDF to ensure it. More info on vdfresearch.org
1 comments
tfha 2496 days ago
A block proposer has a small probability of being able to re-roll the random number a single time, and an exponentially lower probability of getting a second or third chance. And each attempted manipulation costs a lot of money.

Can easily put secure bounds on this and use it for most applications.

link
petertodd 2496 days ago
Additionally you can use iterated hashing: take the block hash b and hash it n times as in H(H(H(H(b)))) etc.

Since hashing is a serial operation, and each hash is a random mapping of input to output, with enough iterations (hundreds of billions) you make it completely infeasible for the miner to even know what the result was by the time they have to make the block public.

Zcash actually did this for their second trusted setup; IIRC the delay was set to be about a week's worth of computation. It's a much better scheme for many use-cases than anything else I've seen in this conversation. The main downside is exactly when which participate actually finds out what the final result is isn't well defined. But for cases where you can commit to the result in advance that's fine.

link
GuthL 2495 days ago
What Zcash did and Solana plans to use is a VDF without succinct verification. Unfortunately, I cannot verify it on a smart contract though, which brings me back to RANDAO + VDF for onchain verifiable randomness.
link
GuthL 2495 days ago
While you are right for most applications, it would not work for gambling or block selection in the case of proof of stake. Let say I'm flipping a coin (based on the last bit of the block hash) with you. You already locked the funds on the contract, waiting for me to commit to. I can wait until I'm the block proposer to push a block where I'm included. Even if we defined ahead of time how many rounds of hashing, I still have access to that information ahead of time and can decide to participate in the bet. Therefore, it is not secure randomness. (I won't get into commit and wait which could solve it but they are a pain in any case)
link
tfha 2495 days ago
No need for commit reveal, just do a relative offset for picking the rng. So after you place a bet, 6 blocks later is the block that decides if you succeed or fail.

You can use simple techniques like this to make most use cases secure.

link