Are pending transactions "dropped" and "reinstated"?

Question

I tried a simple transfer of ether between two accounts using geth, but set quite a low gas price (2 gwei). After two hours the transaction was still showing in geth under eth.pendingTransactions - I assumed this was due to lack of demand to mine at that gas price.

However, at that point I checked both accounts on Etherscan to establish whether the transaction had been broadcast from my local machine. The transaction showed as pending but with an age of only 40 minutes. Around ten minutes later I refreshed, and the transaction had disappeared from both Etherscan pages - but still showed in geth. A few minutes later the transaction had reappeared on Etherscan but age was reset to 2 minutes. From that point I checked intermittently until the transaction eventually completed (four hours after sending), without dropping off Etherscan again.

Since I was concerned for a short time while the transaction had disappeared, I'd like to understand the underlying process a little better. My understanding would be something like this:

1. Transaction sent
2. First shows as pending in geth
3. Propagates to rest of network - eventually visible as pending on all up-to-date nodes
4. "Chosen" to be mined (by a number of miners or just one?) as part of a specific block
5. Once block is completed, the updated transaction status propagates to rest of network
6. When my local copy of geth syncs to that block, change in account balances shows

However, my experience today suggests it may not be so simple, since my pending transaction disappeared and then reappeared from Etherscan (one node?). What would be a more accurate sequence of events?

Answer 1

My understanding is that your understanding is correct, except you're missing one particular property of the Ethereum node software. Namely, as part of #3, the transaction is stored in the node's transaction pool (cf. Bitcoin's mempool). Normally, the transactions live there until mined, but because computers have finite memory and processing power, the transaction pool is, by necessity, also of a finite size. Transactions that have not been mined may be evicted from memory if the transaction pool is full (I assume the ordering is implementation dependent -- presumably, higher value transactions are kept). So your transaction probably got evicted from Etherscan's transaction pool, but was "recirculated" by another node after Etherscan's transaction pool freed up some memory.