0 sats \ 4 replies \ @kenn_b 29 Sep 2023 \ parent \ on: Transaction dropping from mempool bitcoin
You should always assume that it never drops from all mempools. Because someone could be a sneaky bastard and store it and release it to the mempool again at any point later in time.
That is what I always assume too. Also, for example mempool.space has this in their FAQ:
mempool.space uses multiple Bitcoin nodes to obtain data: some with the default 300MB mempool memory limit (call these Small Nodes) and others with a much larger mempool memory limit (call these Big Nodes).
Many nodes on the Bitcoin network are configured to run with the default 300MB mempool memory setting. When all 300MB of memory are used up, such nodes will reject transactions below a certain threshold feerate. Running Small Nodes allows mempool.space to tell you what this threshold feerate is—this is the "Purging" feerate that shows on the front page when mempools are full, which you can use to be reasonably sure that your transaction will be widely propagated.
Big Node mempools are so big that they don't need to reject (or purge) transactions. Such nodes allow for mempool.space to provide you with information on any pending transaction it has received—no matter how congested the mempool is, and no matter how low-feerate or low-priority the transaction is.
So basically, no transaction ever leaves the big node :).
write
preview
10 sats \ 3 replies \ @Murch 29 Sep 2023
Yeah, but Bitcoin Core nodes only relay each transaction once to their peers when they first learn about it. Nodes do not rebroadcast foreign transactions, even when they may have transactions that other nodes have already forgotten about.
reply
0 sats \ 2 replies \ @kakocuro OP 30 Sep 2023
Interesting. Thanks for sharing this info.
Wouldn't this mean though that if the tx is at least in one mempool which does not drop it, then it is still alive, ready to be mined?
reply
0 sats \ 1 reply \ @pillar 30 Sep 2023
Exactly.
reply
10 sats \ 0 replies \ @Murch 30 Sep 2023
Yes, any valid Bitcoin transaction that has been broadcast to the network stays valid indefinitely, unless a conflicting transaction that spends some of the same inputs is mined into a block. That means even if most nodes forget about transactions, you cannot rely on the default behavior of nodes (i.e. the two week timeout and the not rebroadcasting), you need to expect that any transaction you have ever submitted to the network might still get mined, unless it has been replaced. Optimally if you repeat a payment in a new transaction because the old got stuck and eventually dropped, you should use one of the same inputs in the replacement transaction: that way the two attempts at paying the recipient are exclusive, only one can get into the blockchain. Alternatively, you might just want to explicitly spend one of the inputs as soon as you get around to it after a transaction is dropped from the mempool, unless you’re still trying to get it confirmed.
reply