Topic: When can transaction be dropped from mempool (Read 374 times)

Oh, right. Shame that I missed that.
Guess I'll just delete my reply to that post since it's not a genuine question.

Do not mind amirmachi1986, he only just wanted to copy, paste and also probably spam around, I created this thread, you can check the OP, check the third paragraph, amirmachi1986 copied exactly what is on the third paragraph.

Fair enough. I thought some of the responses did highlight that the state of the mempool differs among the nodes and that it is highly customizable.

It is actually wrong if the user is asking about the mempool and the responses are talking about one wallet’s default settings. It’s important to actually understand the things you’re talking about when answering people’s questions because you don’t want to lead someone’s education down the wrong path. If he left here thinking the mempool had a 2 week limit and built a project hinged around that fundamental misconception, it could have costly side effects. Assumptions don’t work when it comes to developers and currency.

While i didn't think about different implementation and it's efficiency, i think it's possible there are ideology involved for other parameter, such as
1. Set minrelayfee lower than 1 sat/vbyte because Bitcoin price will rise and transaction fee will feel more expensive.
2. Accept non-standard transaction () to mempool because it's stupid to froze user Bitcoin due to buggy wallet. An example, [~1 BTC Bounty].

It is not about ideology, just being different code and different implementation. Maybe the other one is less efficient (or more) where the mempool code is in a way that takes up more space in memory (or less) so you have to decrease (or can increase) your node's mempool size when running that alternative implementation which also affects your minrelaytxfee.

It isn't wrong to be talking about the reference implementations though. There isn't any reason for people to be messing with their default mempool size and thus it would be safe to assume that most people which runs the reference client (Bitcoin Core) do not change the various settings that doesn't directly affect them (minmempoolfee, minrelayfee, mempoolsize). Miners probably don't run the reference implementation but if a user creates a transaction after it gets dropped, it would probably have a higher fee and miners would definitely want that transaction to be relayed to them.

While the mempool is unique and specific to each node, your best and most accurate assumption would be based on the typical default behavior of the majority.

There's no indicative evidence of the reason why it stayed longer than 14days, but it's most likely that or the last scenario in my list.
AFAIK, Mycelium is one of the wallets that will rebroadcast dropped transaction, don't know about those custodial services.

I think people would be surprised how many custom implementations of Bitcoin software are used by miners and even regular Bitcoiners who want to help maintain the blockchain without being bound to “defaults” set by some random team of individuals. Thinking about it, it’s actually pretty dumb to claim a “default” setting on the mempool based on one wallet, not to mention incorrect. That’s why the, “I’ve always heard” entered the picture…

Most wallets allows you to remove the transaction and thus avoiding any rebroadcast. Doing so will not prevent someone else from rebroadcasting that TX for you.
Not really stuck per se. Just that any "conflicting" transactions will have poor propagation if it doesn't signal RBF and meet the RBF requirement. Even if there is a poor propagation, there is still a chance for miners to be able to see your transaction if the propagation just so happens that it reaches the miners. The nodes are just intermediaries which increases the chances of a good propagation.

With what I have noticed, wallets do rebroadcast transactions, this happens when the wallet is synchronizing with the blockchain, that is why such wallets are needed to be totally turned off so it will not be able to sychronize with the blockchain for over long time.

Another reason this can occur is what pooya87 said. There are thousands of nodes running full nodes, some nodes can receive a transaction today, while some other nodes can receive the transaction in 4 or 5 or more days after. This can make the transaction to remain stuck if many nodes still having the transaction not dropped.

No doubt that it would be equally easy to find something that displays in the actual decimals but my node returns the values as it is: http://163.172.57.208/getmempoolinfo.txt.

Feel free to refer to that if needed, it is running at default settings as well.

Anyone can rebroadcast the transaction as long as they have the raw transaction (which is something every node has once it is propagated). But yes, that is basically the reason why.

I also heard that the default is ~2 weeks but many times I have experience that it is not. This is an example. The user has waited more than 23 days for his tx to get confirmed.

@nc50lc
Is this because of:
[Question mark]

Armory is not a full node... Armory is a wallet application that connects to Bitcoin Core.


What wallet were you using? Just because you keep your wallet closed, and the transaction drops from some mempools... it doesn't mean that your transaction has been removed from your local wallet.

If the transaction was still being held locally in your wallet, and it was setup to automatically rebroadcast transactions on startup... as soon as you opened the wallet after 1 month, it's possible your wallet simply rebroadcast the old transaction again.

For instance, older versions of Bitcoin Core required that you abandon (and/or zapwallettxes) to remove local copies of transactions that you didn't want to be broadcast any more... otherwise the wallet would rebroadcast it every time you started the application.


You're referring to mempoolminfee? The only ones I know of are: https://mempool.space/


When it goes up it'll saying something like "Purging < 3.5 sat/vbyte" etc.


And the other one is here: https://statoshi.info/d/000000020/memory-pool?orgId=1

The graph at the bottom shows the mempoolminfee.


It's also visible using getmempoolinfo command on Bitcoin Core:

which can actually be executed on the chainquery website here: https://chainquery.com/bitcoin-cli/getmempoolinfo

NOTE: unfortunately it formats the BTC values in scientific notation... ie. 1.0e-5 instead of 0.00001000

Your wallet is not the only one that can rebroadcast the transaction. Anyone with your raw transaction will be able to do so and that includes your recipient as well.

There is really no guarantee that your transaction will ever be drop due to the fact that anyone can rebroadcast your transaction at their will. That is why we normally use opt-in RBF to replace the transaction if it gets unconfirmed for far too long. Some wallets don't check the mempool to see if your transaction has reached its expiry, violated the min fee, etc. In those cases, the transaction can very well remain in your wallet as unconfirmed even when the majority of the network has dropped it.

What you have to keep in mind is that mempool is not a global/shared pool. It is an individual memory that each node has regardless of other nodes. The 14 day (or whatever else) limit is also that individual node's settings not a global setting.
If your node receives transaction A on May 1 you'll drop it on May 15 but if my node comes online on May 4 and receives that transaction I'll drop it on May 18. That means transaction A will remain in my mempool for 4 more days and if during those days any node that doesn't have this tx connects to me and asks for my mempool I'll give transaction A back to them and they'll end up with it in their mempool again.
So technically transactions that are valid will never actually disappear and will always remain out there on bitcoin's network among some nodes.

Armory is not a standalone full node, it is a wallet written on top of bitcoin core.

It's really 336hours (14days) by default after it's received but can be changed in the configuration file by adding this line:

For transaction that stayed longer than usual, there could be a couple of reasons:

• Some wallets, clients and services have a built-in re-broadcast function to make sure that the transaction wont be dropped.
• Every node's mempool might receive a specific transaction at different time making the expiration time different.
• Some nodes have their mempool setting tweaked to larger size to accept more transactions and when a transaction with mempoolminfee got dropped from the majority of the nodes, those "high-mempool size nodes" will still keep it. After the average mempool size got lower, the nodes that dropped it may accept the transaction again from the nodes that kept it, they've just received it so the expiry's basically reset for them.

Yes, definitely 2 weeks on Bitcoin Core, but what about on others like on Armony. I think so far it can be changed on Bitcoin core, it can be changed on Armony also, and which may not be the same.

I know about the fee I can include in a transaction, I also make use of https://mempool.space at times, but I can still set the fee below the low fee suggested and my transaction will not be dropped after more congestion. But I thinking dropping of transaction from the mempool is rear, but I noticed this will occur when wallet are even not accepting such low fee transaction. I think this will do more with how deep the mempool is.

Any miner could really have any mempool setting they wanted and include transactions from 10 years ago (if the inputs hadn't already been spent, etc.) if they were so inclined as far as my understanding goes.  That being said, I don't know what the default is but I've always heard ~2 weeks.



This is the best resource I've found to give you an idea of what fee to include on your transaction:
https://jochen-hoenicke.de/queue/#BTC%20(default%20mempool),24h,weight

I have read about transactions that were dropped from mempool after 14 days, some says this is the standard period for transaction to drop from mempool in a way the sender can be able to rebroadcast the input in of the transaction again.

Some says the 14th day transaction drop is the standard for Bitcoin Core mempools. There are other wallets that run full nodes, I have ever heards of full nodes without having no wallet. Armony wallet is another wallet that runs full node. Is it true the day Armony full nodes to drop stuck transactions can be differ from Bitcoin Core? That is, in a way it can be set to even be some days before or after 14 days?

There was a time I had 4 sat/vbytes transaction unconfirmed for up to three months, I closed my wallet for over a month for not to synchronize with the blockchain, but nothing was reflecting on my balance, and unable to rebrocast the transaction. After over one month, I later had to use my wallet for other transactions, then I noticed the same transaction is getting rebrocasted automatically. But why didn't I able to rebrocast the transaction after making sure the wallet is not synchronizing with the blockchain for over a month after some mempools dropped it already?

The third question is that how can I know the minimum fee required by mempool for transaction to be broadcasted? Is this indicated on any mempool observing site? And if the mempool become more congested after the minimum amount paid, I heard the transaction will be dropped from mempool?