Mempool pool unmined transaction

[promise444c5]

When a memory pool pending transaction isn't picked up by any miner it's beign sent back after 48 days at most , why don't it just get pushed for a miner instead ??  since it will still be resent again and a miner will definitely  mine it or is it just to ease the stress of Sender client from worrying about his sent Btc.

[1714682818]

1714682818

[1714682818]

1714682818

[1714682818]

1714682818

[1714682818]

1714682818

[un_rank]

When a memory pool pending transaction isn't picked up by any miner it's beign sent back after 48 days at most ,

A pending transaction is not sent back, it never even left the sending wallet at any point.
For the transaction to be cancelled it has to be dropped from the mempool of majority of nodes for the transaction making it unavailable for miners to add to their blocks.
The default time for this to happen is 14 days, but can always be higher or lower depending on the nodes specifications.

Note that the transaction can be rebroadcasted at any point during this time.

...why don't it just get pushed for a miner instead ??  since it will still be resent again and a miner will definitely  mine it or is it just to ease the stress of Sender client from worrying about his sent Btc.

There is no definiteness that a transaction will be confirmed. The sender needs to bump the fee most of the times before the transaction can be confirmed.

- Jay -

[Zaguru12]

When a memory pool pending transaction isn't picked up by any miner it's beign sent back after 48 days at most , why don't it just get pushed for a miner instead ??  since it will still be resent again and a miner will definitely  mine it or is it just to ease the stress of Sender client from worrying about his sent Btc.

The default minimum time for transaction to been sent back to the sender address or Wallet is 14 days which also varies because of some factors like the wallet having in an in built rebroadcast feature or base one the Time each node picks the transaction into their individual pool.

The resending will depend on the fee, if the miner drops it and probably other miners have it and later the fee gets lower or mempool gets less congested then the miner will pick it again. Not that it is a default thing that he will re pick it again.

Use a wallet with transaction fee  bumping features so that when this things happen you bump your transaction fee.

[Charles-Tim]

When a memory pool pending transaction isn't picked up by any miner it's beign sent back after 48 days at most , why don't it just get pushed for a miner instead ??  since it will still be resent again and a miner will definitely  mine it or is it just to ease the stress of Sender client from worrying about his sent Btc.

If the fee rate that is getting transactions confirmed at the time is not used, and if the mempool did not become decongested to the fee rate or below the fee rate the sender used, do not expect miners to pickup the transaction.

The default time for mempool to drop an unconfirmed transaction is 14 days. Be expecting the transaction to have been dropped from mempool after 14 days.

[pooya87]

For the transaction to be cancelled it has to be dropped from the mempool of majority of nodes for the transaction making it unavailable for miners to add to their blocks.

Technically the said transaction has to be dropped from the mempool of all nodes not just a portion of them because even if it is only one node out there that stores this transaction, it can continue broadcasting it until it is either confirmed or becomes invalid (eg. double spent).

[tranthidung]

When a memory pool pending transaction isn't picked up by any miner it's beign sent back after 48 days at most , why don't it just get pushed for a miner instead ??  since it will still be resent again and a miner will definitely  mine it or is it just to ease the stress of Sender client from worrying about his sent Btc.

There are many mempools and each mempool has its own settings. The common setting by many mempools result in drop of too low fee rate pending transactions but as pooya87 wrote, not all mempools are the same and if only one mempool does not drop your pending transaction, it can be confirmed.

Memory pool.

In Bitcoin Core there is a memory pool limiter which can be configured with -maxmempool=<n>, where <n> is the size in MB (1000). The default value is 300.

The minimum value for -maxmempool is 5.

Bitcoin Core Config Generator (Jameson Lopp). It uses a default value (300) too.

[Findingnemo]

When a memory pool pending transaction isn't picked up by any miner it's beign sent back after 48 days at most ,

The transaction from the network will be dropped in 14 days not 48 as far as I know, other possible factors due to very low fee that is below the purging level, and once every node drops then it will be dropped from the network even before 14 days or the network may stay forever if your wallet keeps rebroadcasting the transaction with the same fee which is not enough to get into a block but above the minimum fee.

why don't it just get pushed for a miner instead ??  since it will still be resent again and a miner will definitely  mine it

Miners always prioritize the TX with higher fees to maximize their revenue so this restricts the TX with low fee stays in the network in the queue of unconfirmed TX. It doesn't seem logical to pick the TXs with lowers fees by miners unless they really want to. So the only way to make possible your proposal is to set up a pool and only include the TX with a low fee.

is it just to ease the stress of Sender client from worrying about his sent Btc.

The TX status will remain the same as long as they are sent with the same fee so it's the responsibility of the sender to increase the TX fee if they want their TX to get confirmed faster.

They can increase the fee using Replace-By-Fee (RBF) or Child-Pays-For-Parent (CPFP) even if they transacted with a low fee accidentally.

[khaled0111]

I'll share my experience her so you understand how wallets and nodes work.
Few weeks ago (more than two weeks)  I've made a transaction and broadcast it with 1 sat/vb for testing purposes. It has been broadcast but few minutes later it has been rejected and my Electrum wallet showed it as local, so I've deleted it.
Yesterday, I opened my wallet and was surprised to see the transaction is still there and waiting for confirmation. The first time I saw it, I thought my wallet was compromised and some one was trying to steal my money till I remembered it was me who've created this transaction.
I thought it has been rejected by all nodes and I'll never see it again, well, I was wrong 😅

[pooya87]

I'll share my experience her so you understand how wallets and nodes work.
Few weeks ago (more than two weeks)  I've made a transaction and broadcast it with 1 sat/vb for testing purposes. It has been broadcast but few minutes later it has been rejected and my Electrum wallet showed it as local, so I've deleted it.
Yesterday, I opened my wallet and was surprised to see the transaction is still there and waiting for confirmation. The first time I saw it, I thought my wallet was compromised and some one was trying to steal my money till I remembered it was me who've created this transaction.
I thought it has been rejected by all nodes and I'll never see it again, well, I was wrong 😅

This oddity is probably because your client changed server behind the scene (automatic server selection must be on) which means in first attempt you sent the transaction to a node with a bigger mempool size which accepted it and kept it in its mempool. Then your client changed server and tried syncing with the other one that had a smaller mempool size which meant it rejected the low paying tx turning it into local.
The next time you opened Electrum you again connected to a node with bigger mempool that had your old tx hence showing it as pending!

[Synchronice]

When a memory pool pending transaction isn't picked up by any miner it's beign sent back after 48 days at most , why don't it just get pushed for a miner instead ??  since it will still be resent again and a miner will definitely  mine it or is it just to ease the stress of Sender client from worrying about his sent Btc.

So far, as I understood, you mean that when you send transaction with low fee that is not enough to get confirmation, transaction is stuck in mempool for 48 days and then gets cancelled and your question is, why doesn't it gets rebroadcasted again automatically with the hope of getting confirmation in near future? Am I right?

Okay, it has more pros than cons. If you send transaction without enabling RBF and can't do CPFP, then you will be able to get your coins back when nodes forget your transaction and you'll be able to resend them. Otherwise, if it was rebroadcasted frequently, then your transaction could probably be stuck for months and even more or forever if fees are going to remain permanently higher than what you paid. But there we have FULL RBF feature that will give everyone possibility to increase their transaction fee and get rid of waiting for confirmations forever.

[promise444c5]

I'll share my experience her so you understand how wallets and nodes work.
Few weeks ago (more than two weeks)  I've made a transaction and broadcast it with 1 sat/vb for testing purposes. It has been broadcast but few minutes later it has been rejected and my Electrum wallet showed it as local, so I've deleted it.
Yesterday, I opened my wallet and was surprised to see the transaction is still there and waiting for confirmation. The first time I saw it, I thought my wallet was compromised and some one was trying to steal my money till I remembered it was me who've created this transaction.
I thought it has been rejected by all nodes and I'll never see it again, well, I was wrong 😅

This oddity is probably because your client changed server behind the scene (automatic server selection must be on) which means in first attempt you sent the transaction to a node with a bigger mempool size which accepted it and kept it in its mempool. Then your client changed server and tried syncing with the other one that had a smaller mempool size which meant it rejected the low paying tx turning it into local.
The next time you opened Electrum you again connected to a node with bigger mempool that had your old tx hence showing it as pending!

So you are saying  mempool have sizes and they are different from each other or this is determined  by the node you're broadcasting on.

[Catenaccio]

So you are saying  mempool have sizes and they are different from each other or this is determined  by the node you're broadcasting on.

Each mempool can set different memory pool and they can set their max mempool size, mempool expiration.

Like this
https://jlopp.github.io/bitcoin-core-config-generator/
This example setting has max mempool size is 500 megabytes, mempool expiration (hours) is 336 = 14 days.

mempoolexpiry=336 (hours)

mempoolminfee =0.00001000
mempoolminfee is used to set min fee rate and transactions with lower fee rate than this will be dropped from a mempool but it can be kept in other mempools that have min fee rate is lower than this.

https://chainquery.com/bitcoin-cli/getmempoolinfo

getmempoolinfo

Returns details on the active state of the TX memory pool.

Result:
{                               (json object)
  "loaded" : true|false,        (boolean) True if the mempool is fully loaded
  "size" : n,                   (numeric) Current tx count
  "bytes" : n,                  (numeric) Sum of all virtual transaction sizes as defined in BIP 141. Differs from actual serialized size because witness data is discounted
  "usage" : n,                  (numeric) Total memory usage for the mempool
  "total_fee" : n,              (numeric) Total fees for the mempool in BTC, ignoring modified fees through prioritisetransaction
  "maxmempool" : n,             (numeric) Maximum memory usage for the mempool
  "mempoolminfee" : n,          (numeric) Minimum fee rate in BTC/kvB for tx to be accepted. Is the maximum of minrelaytxfee and minimum mempool fee
  "minrelaytxfee" : n,          (numeric) Current minimum relay fee for transactions
  "incrementalrelayfee" : n,    (numeric) minimum fee rate increment for mempool limiting or replacement in BTC/kvB
  "unbroadcastcount" : n,       (numeric) Current number of transactions that haven't passed initial broadcast yet
  "fullrbf" : true|false        (boolean) True if the mempool accepts RBF without replaceability signaling inspection
}

Examples:
> bitcoin-cli getmempoolinfo
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getmempoolinfo", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:8332/

[pooya87]

So you are saying  mempool have sizes and they are different from each other or this is determined  by the node you're broadcasting on.

Yes. Certain settings are a matter of preference that can be set by the node operator, such as the size of the mempool or even what transactions you accept in your mempool. For example the node I run is set to reject the spam attacks like the Ordinals Attack transactions.