There are several questions here.
Please correct me if I'm wrong: The miner validates the newly received block before using it themself and sending it to their other connected peers.
Yes and no. Note that by miner we're talking about people who build blocks themselves - that includes solo miners, pool operators, and p2pool users. Hashers that only connect to a pool and perform work are not part of that group.
Miners can - and sometimes do - build a new block before they've fully processed the previous one (even if it's their own), to avoid time not mining. Unfortunately, as they don't yet know which UTXOs are spent in the just-received block, they don't know what follow-up transactions are valid, and thus can't include any new transactions. Because of this, these blocks will be empty apart from the coinbase.
In practice, these miners will have two mechanisms to update the proposed block their hashers are grinding on:
- A new best block hash is announced within their own network (or detected on another pool's network - for example by listening to their pool interface, or by an agreemwnt to send each other information). When this happens, all hashers are told to start working on an empty block.
- A new block is received through their
bitcoind (via the P2P protocol, via the submitblock RPC command for their blocks, or via separate relay networks like FIBRE). bitcoind then builds a new set of valid transaction on top (through the getblocktemplate RPC), and they update their hashers to start working on a block with these transactions.
The assumption is that when (1) happens, the same block will shortly go through (2), and we'll switch from working on an empty block on top to a normal block on top. There was once an incident where this did not happen.
When BIP66 activated, some miners running a BIP66-enabled bitcoind versions were listening in on blocks sent by pre-BIP66 pools. A pre-BIP66 miner produced a non-BIP66-compliant block (wrong version numbers), and BIP66-enabled miners listened in, and started producing empty blocks on top. Of course, their bitcoind never accepted the full block as it was invalid according to the new rules - rules those themselves miners agreed to. The result was a sequence of many empty blocks on top, with many miners building on top of the previous invalid blocks, all of which were not accepted by the network.
So to answer your question:
So why keep mining on top of the previous block?
Because the new one may be invalid. It's unlikely to happen intentionally due to the costs of mining an invalid block, but it can happen as a result of software or manual bugs. Furthermore, we should not build infrastructure that relies on this not happening - as doing so might over time make such attacks cheaper.
How long does this process typically take? What does it depend on?
In your process you're only counting block validation. But the whole process consists of everything between (A) the creation of a valid block on the network and (B) hashers switching to building a block on top of it. This includes:
The previous block creator getting the block out to the network. There may be unintentional delays here, or even intentional delays (like a Selfish Mining attack).
The blocks needs to propagate across the network. Normal bitcoind nodes only propagate after full validation, and require bursts of high bandwidth to transfer all blocks. More recent technology like Compact Blocks (BIP152) and FIBRE avoid full resubmission or even waiting until validation completed.
The blocks need to be validated.
A new set of valid transactions on top has to be created.
Validation depends on many factors:
- Software version. There are constantly improvements to validation speed.
- UTXO cache size. The larger the cache, the less database access is needed to retrieve information about the outputs being spent. As a result, just fetching of inputs can take from a few milliseconds to a few seconds.
- Signature cache size and CPU speed. The larger the cache, the more signature validations can be avoided. These validations - depending on the software version and hardware can vary from 0.01ms to 0.6ms per signature (45ms to 2.7s for a block).
- Correlation between the memory pool and the new block. If a block contains transactions that a node hasn't seen before, its inputs and signatures are less likely to be cached before.
- Bandwidth. Prior to Bitcoin Core 0.13, blocks were always submitted in full between peers, which can cause big spikes at the time a new block is announced.
- Network latency. In more isolated parts of the world, even with good bandwidth, the time it takes for a network packet to reach the outside world can be significant. Depending on the protocol, 1 to 3 roundtrips are needed to send a block. If the latency between two peers is 200ms, that can already mean 1.2s wasted on going back and forth.
- Number of connections. If a node has many connections, it will try to broadcast a new block simultaneously to all, causing a spike of work of network activity. This can be too much for the CPU or network hardware or bandwidth to handle, causing slow downs when many connections exists.
The time to construct a new block mostly depends on software version. In older versions it was up to a few seconds, but lately is has been reduced to tens of milliseconds.
Is it done on specialized mining hardware or on a general-purpose CPU?
As far as I know, no custom hardware exists for block validation or block construction.
Is it correct that the time block validation takes is linear to the block's + witness's size should segwit activate?
Mostly. There exists an inefficiency in the currently signature hashing algorithm that can be O(n^2) in the size of transactions. This can result in single transactions that take minutes to just compute the signature hash. This is fixed in BIP144, which is always used inside SegWit transaction inputs, making it O(n) at worst (less than 10ms for a block in the worst case on common hardware).
Longer term, there are other factors that play, like the size of the UTXO set. If this would grow to multiple gigabytes, and not fit in typical memory caches, the UTXO fetch time for validation could go up dramatically.
Also: How long does it take on average for a block to be propagated through the network? It'd be great if that average is weighted on the receiving miners' hashing powers.
That's complicated. It's certainly not proportional to hashing speed, but more related to network topology and used technology. The FIBRE website has some statistics, but often transfers in less than 20ms more than the minimum theoretical network latency (speed of light across long connections) across the globe. This is only possible by being a private network that assumes its participants will not engage in DoS attacks on the network. The public network is much more robust, but often takes many seconds to propagate a block to large portions of nodes, and dozens of seconds to reach less connected nodes.
