Case 1
I receive a new block and I verify it including the contained transactions. My blockchain now contains the 3 valid blocks A,B and C
Right.
However, it is better to think of it as a block-tree rather than a blockchain. The blockchain is just the longest path though the block-tree.
Case 2
This follows the case 1 situation. I receive a new block that appears valid, but is built on block B, and not on block C. I now have two blocks C1 and C2, and C1 is stored in my blockchain. I ignore block C2.
This works based on
headers first. The other node should send you C2.header first. Your header tree now stores C1.header and C2.header. Each node points back to its parent. So C1.header and C2.header point back to B as parent. There is also an array storing the main chain for fast lookups.
C1.header still counts as the longest chain, since ties are broken based on which header was received earlier. This is called the "tip".
You don't ask for block C2 since it isn't on the longest chain, as you understand it.
Case3
This follows case 2. I receive a new valid block that is built on C1. I add this to my blockchain and call it block D, and I throw away block C2
You don't throw away anything. Even if you had downloaded C2 in full, you just leave it on the disk. C2.header is left in the database.
There are few enough orphans that it doesn't make much difference.
This allows blocks to be stored using "append-only" files. You just keep adding new data onto the end of the blk****.dat files.
Case 4
This follows case 2. I receive a new valid block that is built on C2. I delete C1 from my blockchain, and I add C2 and D. I discard C1
You would download D.header first. This means that your header tree shows that D is the longest chain. This is called a re-org.
Each block is matched with "reverse" information in the rev****.dat files.
You would then reverse C1. This deletes all the outputs of transactions in C1 and adds back all the transaction outputs that C1 spent from the unspent transaction output (UTXO) database.
The tip is now at B.
You would then download C2 and apply it to the transaction output database (and also create the reverse data) and then download and apply D.
The block tip is now pointing at D.
What happens to my mempool, as it may contain a mix of transactions from blocks C1, C2 and D. Do I take the mempool from the miner who created block D?
The reverse also adds back all the transactions in C1 into the mempool. Then moving forward will remove all the transactions in C2 and D from the mempool.
Now, how am I contributing to the confirmation process? It seems to me that I would only have some influence in the unlikely event that a miner picked up my files.
Running a full node and not actually using it doesn't help that much for fork prevention. The contribution you are making is to help SPV clients to connect and it makes it easier for new nodes to download the blockchain.
If you don't actually use the node for transactions, then it doesn't matter what your node does if there is a fork. It doesn't prevent other people form spending their bitcoin.
If you were a merchant and were using the node, then forking your node off the network would prevent people being able to spend bitcoins at your store. That is where the anti-fork resistance comes from.
If 75% of the miners were to implement a hard-fork, then many merchants and exchanges would refuse to accept their forked bitcoins. They would have more POW on their chain, but most nodes would consider it invalid and not bitcoin.
If most of the merchants, users and exchanges agree to the hard fork, then the ones on the old chain would end up not being able to spend their coins.
