The publicKey must be revealed before the wallet can inject an operation to the blockchain. The client (and most wallets) will automatically add a reveal operation onto the first operation you try to perform with the new address. E.g. sending xtz or an fa1.2/fa2 token, delegating to a baker or originating a contract, will all trigger a reveal operation first
According to the docs:
The seed of cycle (n-PRESERVED_CYCLES-2) is hashed with a constant
and then with each revelation of cycle (n-PRESERVED_CYCLES-1).
Once computed, this new seed is stored and used during cycle n.
Based on this, there is no min threshold of revelations required.
These are very different operations...
activate_account is an anonymous operation that bootstraps the account with some coins purchased during ICO. So, this is for the ICO participants only. Or for the testnets' faucet.
reveal is a manager operation that shows everyone your public key, so that everyone can verify your signature in subsequent operations.
I think the baker who generates the revelation does not earn anything (it just doesn’t lose its other rewards). It is the baker who includes the revelation that receives the reward (usually, in the first block of the next cycle).
If you have a smart baker, you could delay your revelation to your fist block in the cycle.
Also, not all blocks trigger a ...
according to the doc :
bakers generate and hash a random number using commitments made during cycle (n-PRESERVED_CYCLES-2), in one out of every BLOCKS_PER_COMMITMENT = 32 blocks.
As a baker have to add a nonce_hash in only one out of (BLOCKS_PER_COMMITMENT = 32) blocks.
take a look at that block 315648 notice the field Nonce Hash
is filled with ...
The problem is not the number of nonces revealed, but the number of bakers revealing. If only one baker reveals one or more nonces, he could try to compute the nonce so that he will receive more baking/endorsing slots in the future. The more different are the bakers who reveal, the less likely they can cooperate to do that...