> The technical solution is straightforward: longest chain wins.

One caveat here is that "longest chain" is measured not in blocks but rather in cumulative difficulty. So the fork with more hashing power, having a higher difficulty per block, will mine a "longer" chain over the same time period.

> The real issue is a social one: how do you deal with finding out that the last N months worth of transactions are just gone?

If the transactions are still valid (i.e. the inputs haven't been spent in diverging transactions on both chains) then they can be reintegrated into new blocks on the winning fork after the partition heals.

The real problems come from double-spends, whether deliberate or accidental; if funds were moved from TxA to InB in one chain and from TxA to InC in the other then only one of these can be retained, and all transactions downstream from the losing version will be nullified.

In general, to create such a situation a client would need to be aware of both forks and sign conflicting transactions for the same unspent output. There is one major exception, however, which is that the coinbase transactions introducing new block rewards on the losing fork can never be valid inputs for transactions on the winning fork. Ergo, any transaction which depends on recently mined coins is ineligible for reintegration.

If I'm stranded in Antarctica, and decide to compute hashes with my pocket calculator to pass the time, and drop the difficulty to zero (because I can do one hash every 10 min, so they all have to be winners), does the bitcoin protocol say that my chain of empty blocks is a valid contender for longest chain? Or does "longest chain" also take into account difficulty? (Setting aside the obvious fact that in reality everyone would obviously just ignore me)

This isn’t quite how the algorithm works.

To make a valid block, you have to start with another valid block. The difficulty is set (edit: I was wrong, and I fixed this) every 2016 blocks based on how long they took to mine. This works out to about 2 weeks at the expected rate of mining. The average time of those 2016 blocks is then used to calculate the difficulty of the next 2016 blocks, and the difficulty is marked down in the chain itself.

So in your hypothetical you’d have to solve around two weeks worth of blocks at the current difficulty level, which isn’t possible in a human lifespan. After that the difficulty for your chain would rapidly fall, but your sub-chain would already be very far behind and would never catch up.

That makes sense, I remembered that it adjusted every 2 weeks, but I forgot that the 2 weeks was actually measured in blocks, not wall time.

In practice you wouldn’t be able to mine at all, because the difficulty updates infrequently, so you would have to mine several blocks at the old difficulty. Obviously this is impossible on a pocket calculator.

I’ve always assumed that the notion of longest chain takes difficulty into account, although I haven’t really been able to find confirmation of this.