Bitcoin block hashes are expensive to manipulate, but not fundamentally difficult to manipulate. All you need to do is bribe the miners. Let's say you strike a deal with AntPool, which mines about 10% of Bitcoin blocks. If they find a block with favorable entropy, they broadcast it; otherwise, they withhold it, and you compensate them for the missed coinbase. So if you only need to control 1 bit of entropy, you can expect this bit to be available within ~20 blocks, at a cost of one coinbase. Very expensive -- but not difficult.

In essence, the difference between Bitcoin and an aggregate scheme is that in Bitcoin, your control over the entropy is probabilistic and directly proportional to the number of bribed parties, whereas in an aggregate scheme, you have no control whatsoever until you manage to bribe every party, at which point you gain full control.

The effect of this can be minimized by pre-comitting to which block will be used for entropy. Then antpool has a 10% chance of mining the relevant block, a (.1*.5=0.05) 5% chance of mining an unwanted bit and discarding it, and then from there the chance that another unwanted bit is found will be close to 50%.

All considered that means antpool has a 2.5-3% chance of flipping an wanted result into a wanted result. At $125,000 per block, that's $4 million of cost per bit manipulated favorably, getting exponentially worse as you need to manipulate more bits.

I think that the problem is that if you pick the first block mined after April 1st midnight, and there are two competing blocks, it will be a problem. In the blockchain one of the blocks will win sooner or later and it will be extended with a long enough chain to kill the other block. But the people that would have won the lottery with the other block will be angry.

And remember that the timestamp of the block is oply an approximation. You can use any time you want. I'm not sure if the net reject the block when the time is too off, but you can use a fake delayed time of a few minutes and wait to broadcast it (perhaps mining secretly the next block), or perhaps you can use a fake previous time of a few minutes and blame the delay of the broadcast to a bad connection. (It's mode difficult to do this secretly in a pool.)

The newspaper here make a big fuzz about the first baby of the year, and I always suspected the exact born time in that moment is not reliable.

You can solve this problem by picking a specific block height, and not confirming the result until it has at least 6 confirmations.

I think this claim is ought to be very controversial, I seriously doubt anyone would consider Blockchain a viable source of true-randomness.

Why? Please provide a meaningful reason why Bitcoin cannot be used for secure randomness.

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

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.

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.

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.

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)

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.

Having many sources makes it even more difficult to manipulate.