5
It sounds like transactions in discarded blocks are propagated back to the network to be included in the next block to be generated, is that the case? If so, is that triggered in the client when it discards a fork and accepts the longer chain?
I see some info and discussion on this in the protocol and forums, but it's not entirely clear, and sounds like the heuristic is somewhat complex and non-deterministic (eg, some transactions can just be lost).
4
The client will import all the lost transactions into its pool of transactions it's trying to commit. Miners will include those transactions into blocks mined for the new chain, if they're not already in it.
Since a miner won't keep a conflicting transaction in memory anyway, it's not possible for the client to cause a conflict by accepting the transactions in the blocks that are undone. Miners should immediately accept all transactions that meet its transaction fee policy and fit as many of them as they can, in priority/dependency order, into blocks they mine.
Of course, coinbase transactions (the payment for mining a block) are forever lost. This is the primary reason that many more confirmations are typically required before coins from these transactions can be spent.
Does this mean that after the March 2013 fork was resolved, 31 blocks of orphaned transactions got sucked over into the newly validated highest chain? Is there a block that contains some huge number of transactions that got swept up from the orphaned chain? – pinhead – 2013-10-16T23:48:30.760