pull down to refresh

Very cool.
Something I have always wondered: how are confirmed transactions handled on a stale chain? Does Bitcoin Core automatically load them back into its mempool?
That’s a really good question!
@murch probably knows. I don’t want to just guess.
reply
Two blocks at the same height can have an overlapping selection of transactions, because from the perspective of either chain the competing block is not part of the best chain. So, if there are two blocks at height 100, most of the transactions in block 100_a would also be in block 100_b, and vice versa. Now any miners that are currently considering block 100_a the best chain would try to include any transactions that are not confirmed in block 100_a into a new block block 101_a. For them it does not matter if transactions might be already confirmed in block 100_b, because the 100_b is not part of its history. For a miner that is currently working on extending from block 100_b, they would similarly ignore the content of 100_a.
If now say 101_a were found next, everyone would notice that the chaintip with 100_a and 101_a has more work than the chaintip with 100_b. Nodes and miners currently on 100_b as the chaintip would roll back block 100_b and apply blocks 100_a and 101_b. Any transactions that were confirmed by 100_b would first be returned to the nodes’ mempools and then removed according to the blocks 100_a and 101_a. Whatever is still in the mempool after, is simply ready to be included in a block.
TL;DR: Chaintips are like highlander, there can only be one, and all the other ones might as well not exist, but nodes will change their mind which one it is, if a different one pulls ahead in total work.
reply
Oops: that should read "apply blocks 100_a and 101_a."
reply
Fantastic answer, thank you.
reply