Receiving vs. Building the block:
During the mining process, the miner assembles a set of transactions and other data to be put into the block header.
He doesn't "receive a block to mine" , he crafts a candidate block with a Coinbase transaction and with transactions aggregated from the mempool.
As stated before miners do not get a block to mine, they compose it from data like pending transactions, previous block info and an (unknown) number they need to guess.
What was originally called "mining" involves a process that was divided into two parts when mining pools were created. Part 1 is "building the block" and part 2 is "hashing the block". If you are solo-mining, then you are BOTH building the block (as described by ranochigo, Xynerise, and JohnB31 above) AND hashing the block. If you are mining in a mining pool, then the pool is handling everything except the hashing. The pool maintains the blockchain, mempool, and UTXO, communicates with the bitcoin network, and builds the blocks. The pool participants generally receive a partially hashed block header (often called a midstate) from the pool and then handle hashing that midstate with the various nonce values. The pool participant notifies the pool whenever it has succeeded at a difficulty that is lower than the current bitcoin difficulty. That is how the pool can tell if you are actually hashing even if you don't succeed at solving a real block. Sometimes that notification also qualifies for the actual bitcoin difficulty. In that case, the pool handles broadcasting the block to the rest of the network.
Competing blocks:
other miners have to vote with their hashpower ON the block that they consider valid.
This makes it sound like there is a separate "voting" process where the block with the most "votes" wins.
In actually, every solo-miner or pool just assumes that the block which they received first is the "real" block, and attempts to mine a new block on top of it. If they complete a block, then the chain they are building becomes the longest and the block they mined on top of "wins". If, before they can complete a block, they receive a valid block from a peer that lists as its "previous block" that block that they were attempting to mine on top of, then that becomes the longest chain and the block they were attempting to mine on top of "wins". If, before they can complete a block, they receive a valid block from a peer that lists as its "previous block" the block they are NOT attempting to mine on top of, then that other chain becomes the longest, they mark the block they had been trying to build on top of as not part of the blockchain and they build a new block on top of the block they just received.
So, there isn't really a "vote". There is just miners assuming that the first block they received is "correct" until they receive a longer chain.
Miner C then found and published a block building on miner A's block.
The blockchain including miner A's block is the longest chain with the highest cumulative difficulty because it has the difficulty of the previous blockchain + that of miner C's block .
If other miners "vote" by building their block tip on miner C's block, then it becomes the valid block chain and the block by miner B gets orphaned.
The blockchain including miner A's block is the longest chain with the highest cumulative difficulty because it has the difficulty of the previous blockchain + that of miner C's block .
If other miners "vote" by building their block tip on miner C's block, then it becomes the valid block chain and the block by miner B gets orphaned.
Actually, the "vote" was happening while miner C was building his block. He was the "voter" that won the vote by extending one of the two chains. When miner C broadcast his completed block, the vote was over, and miner A's block "won". All miners will switch over to mining on top of miner C's block.
Let's use numbers.
Let's say The current block height the miners are building on is block 100 with block header hash 000....100x
Then miner A finds a valid block that builds upon this, which should be block 101, with blockheader hash 000...101a
However miner B also finds a valid block also building on block height 100 with hash 00..101x, which is also a competing Candidate for block height 101.
Right now there are 2 block 101's -- that of miner A and that of miner B, and there's a temporary bifurcation in the blockchain. full nodes will store both blocks till it is resolved
Let's say The current block height the miners are building on is block 100 with block header hash 000....100x
Then miner A finds a valid block that builds upon this, which should be block 101, with blockheader hash 000...101a
However miner B also finds a valid block also building on block height 100 with hash 00..101x, which is also a competing Candidate for block height 101.
Right now there are 2 block 101's -- that of miner A and that of miner B, and there's a temporary bifurcation in the blockchain. full nodes will store both blocks till it is resolved
Just to avoid confusion, be aware there is no need for the block height to be part of the hash. It would have been just as valid to say that block 100 hash block header hash of 000...37ed, and that the two blocks at height 101 have hashes of 000...a3f2 and 000...2c49. Using the block height in the hash value in the example just makes it easier to visually keep track of which block is being discussed.
Then the miners will vote with their hashpower on the block they consider to be valid.
Both are "valid", the question is which is to be added to the blockchain. Saying that they "vote" is just a slightly confusing way of saying, that they will hash a new block on top of the block that they received first, and someone will eventually finish their new block first.
so his block is "more valid" than B's
It isn't any more or less "valid". It is just currently part of the longest chain (greatest proof-of-work) and therefore accepted as the current blockchain.
if other miners agree with miner C and extend the blockchain by building on miner A's block, then miner B's block will get orphaned by the nodes.
We can assume that the blocks from A and C are actually valid blocks (otherwise they would have been ignored by everyone in the first place and there wouldn't be a "competing block" situation. Therefore, the only reason other miners would not "agree" would be if some miner D happened to complete and broadcast a block built on top of the miner B's block at nearly the same time as miner C was broadcasting his block. (in which case the competing chains would be 2 blocks long and the process would continue in the same way.
In a rare scenario (eg the 0.8 bug) where after miners up to block 104 Are mining on the block found by A, and other miners decide to mine on the block found by B instead and overtake the length of the chain of A with higher hashpower, then the blocks found from 101 - 104 built on the block found by A will be orphaned and the blockchain will reorganise to the new chain with the highest cumulative proof of work.
Correct. At any time, if enough hash power all agrees to ignore the longest chain and build on some older block in the chain, then it is possible that they can overtake the current chain in length (total proof-of-work) and cause a re-organization to the blocks in their chain.
Therefore a transaction mined in miner A's block 101 that now has 3 confirmations (3 blocks built on top), will be orphaned and invalid if the transaction was not included in any of the subsequent blocks found.
This is not true. The BLOCKS will become orphaned. But the transaction will be neither orphaned NOR invalid. It will simply return to being UNCONFIRMED. It will only become invalid if some OTHER transaction in the new chain spends the same inputs.
This is why you should wait for 6 confirmations before you consider a transaction valid even though block reorgs usually do not have a depth of more than 2 blocks.
There is nothing magic about the number 6. You could wait 5, or you could wait 7, or any other number that satisfies your own personal risk tolerance. It is possible to have 10 (or more) confirmations, and then for a re-org to wipe out all of those confirmations. It is also possible to have 1 confirmation, and then discover after a re-org that the transaction suddenly has more than 8 confirmations.
Re-orgs that are more than 2 blocks are extremely rare. If one should happen, then it is very likely that the transaction is already confirmed in the new chain. Even if it is not already confirmed in the new chain, it is very likely that the transaction is still valid and simply waiting to be confirmed in the new chain.
The important factor in determining the valid chain is the one with the MOST proof of work, not the longest chain alone or else it would be trivial to fork bitcoin, reduce the difficulty and mine several blocks ahead of the main chain, forcing a block reorg of the "true" chain to my fake chain.
Under normal circumstances, the chain with the most blocks is always also the chain with the most proof-of-work. This is because difficulty is adjusted by everyone independently in exactly the same way. Simply adjusting your own difficulty would be insufficient. You'd need to get EVERYONE else to adjust their difficulty as well if you wanted to perform the attack that you are claiming is "trivial" (otherwise they'll all see your block as invalid). There are 2 ways to get everyone else to change their difficulty. One is to somehow convince everyone into running a modified version of the protocol (this is what Bitcoin Cash has done to separate their difficulty from the Bitcoin Core difficulty). The other is to go back farther than at least one difficulty adjustment and mine blocks with different timestamps. In this way you can "trick" the difficulty adjustment calculation into calculating an incorrect difficulty. As you pointed out, even if you had enough hash power to pull off such an attack and catch up with the current network in number of blocks, you'd fail to force a re-org because your chain would have less total proof-of-work. If you have enough hash power to get more total proof-of-work, then there is no need to mess around with difficulty since you'll have enough hash power to have more total blocks.
