Topic: I created a transaction 2 weeks ago (Read 271 times)

Yes. If you have made a low fee transaction which is not opted in to RBF, then you have to wait for it to be evicted from mempools before you can replace it. If it is never evicted, you can never replace it (until full RBF becomes widespread enough).

Also correct, unless he can replace it via full RBF.

The obvious solution is just to enable RBF on all your transactions.

I don't know who does that but in the last 6 blocks (from block 791478 to 791483), someone added transactions with 20-22 sat/vByte fees. A highest percentage of transactions in these blocks are added.

So, if majority of node runners significantly increase their limits, for example from 300MB to 3000MB and if they also increase the number of hours a transaction can stay in a mempool, then this means that node runners can also worsen the whole bitcoin transaction drama if they intend to do so.
Also, if someone accidentally sends a huge transaction without enabled RBF and won't be able to do CPFP and I'll intentionally decide to worsen his quality of life, then I can succeed by frequently broadcasting his transaction, right? Oh, that's terrible, man.

If you broadcast a newer transaction with a higher fee anyway to one of the "mempoolrbf=1" v24.0 nodes, then you can circumvent that, as you know. But assuming that the transaction was made by a custodial service, and their software stack is not modern enough to be aware that some feature like this exists, I don't expect them to use this avenue for a while (maybe several years or something).

This is well understood. I am going to read up on RBF and CPFP. I believe it is this recent mempool congestion that made those words to be in rampant usage and that is how I got to know about them.
Thank you o_e_l_e_o  and hosseinimr93 for this, and Op I am sorry for stealing  hijacking your thread.  But it's worth it, I leave it for you now.

Not at all. If an unconfirmed transaction is opted in to RBF it is very easy to cancel it with a conflicting transaction. Full RBF is also being slowly enabled across the network, which will mean any unconfirmed transaction can be replaced.

That's incorrect. The recipient of a transaction has no power to reverse or cancel a transaction. Their abilities are limited to performing a CPFP in order to speed up the first confirmation.

Nodes generally only relay a transaction to other nodes when they first receive it. There is no reason for nodes to continuously broadcast every transaction in their mempool. So if one or two nodes are running with much higher limits and still have OP's transaction in their mempools, they will generally not rebroadcast it to other nodes which have dropped it unless they are told to do so. So when the majority of nodes have dropped OP's transaction, he can broadcast a different one spending the same inputs and it will be accepted.

It doesn't matter who broadcast the transaction; what matters is what wallet is receiving it. If it is being received in to a wallet where OP has control over the receiving address, such as Electrum, he can use that output to perform a CPFP. If it is being received in to a centralized wallet belonging to a third party, then OP has no control over that address and so cannot perform a CPFP.

It's possible that a node has a different setting and keep a transaction in its mempool for a very long time. But that doesn't matter at all. The majority of nodes will probably drop the transaction from their mempool and OP will be able to broadcast a new transaction. The problem here is that coinbase may rebroadcast that transaction.


You can do CPFP if you have control over an output of the transaction. In other words, you need to have the private key of one of receiving addresses.
If you have withdrawn bitcoin from an exchange to an address you have full control over it, you are able to do CPFP. The problem is that withdrawal transactions made from exchanges usually have a large size and doing CPFP for them would be expensive.

Oh! Thank you so much. This is my first knowledge of this. I have always thought that any transaction that is initiated must be confirmed, even if not at the expected time but surely it would be confirmed even if it took for ever. I have just being naive these while. I also thought that the only means to negate the transaction is for the anticipated reciever to sign a message to alert the network to reverse the transaction. (Just my weird reasoning when I don't know how things happen)

@o_e_l_e_o, the way you explain these technical stuffs as if they are ordinary amazes me. You do more than many university lecturers in my country who are paid hugely yet they don't explain ideas and hypothesis in a reasonably connected way.

Regarding the case of Op.
How sure are we that Op's transaction did not fall in the category of node's mempool as you explained here.
If the transaction is stocked in a node with much higher limit which might not drop the transaction at all. What will be the fate of Op. Does CPFP method of accelerating transaction I read somewhere not work for transactions broadcasted by CEX?

Each node has its own mempool. Each mempool has limits as to how long it will keep an unconfirmed transaction in its mempool, or how large the mempool can be.

By default, a transaction will stay in a mempool for 336 hours (14 days) until it is dropped. Code here: https://github.com/bitcoin/bitcoin/blob/3132ec64d9e0f7af88e61ac35807f44315a5ca96/src/kernel/mempool_options.h#L23-L24

By default, the maximum mempool size is 300 MB. Code here: https://github.com/bitcoin/bitcoin/blob/3132ec64d9e0f7af88e61ac35807f44315a5ca96/src/kernel/mempool_options.h#L19-L20

For a node running these default settings (as the vast majority of nodes do), then if a transaction is unconfirmed for 14 days, the node will drop it from its mempool. Similarly, the transaction can be dropped out of the bottom of the mempool because the mempool is filled with 300 MB or more of higher fee paying transactions.

Nodes are free to change these limits, however, and some do, running with much higher limits so they rarely, if ever, drop transactions.

If a transaction is dropped from the majority of mempools, that doesn't make it invalid. It is still a perfectly valid signed transaction, just one that the network has forgotten about. Anyone who has a copy of that transaction (which includes each and every node which once knew about it) can rebroadcast it and try again to get it confirmed. Alternatively, if the transaction has dropped, the person who made that transaction could instead attempt to spend those coins in a new transaction. This new transaction would not be rejected as a double spend since the majority of the network has forgotten about the original transaction.

I wouldn't call it a reversal if a transaction permanently drops - more that the transaction never happened at all.

Then the seller is left out of pocket.

In OP's case here, a few days after he broadcast his transaction, all nodes running default settings would have dropped it out the bottom of their mempools as their mempools contained more than 300 MB of higher paying transactions. Yet we can still see it on every block explorer we check, meaning that at some point someone (probably Coinbase) rebroadcast it to the network.

Each node has a mempool which includes unconfirmed transactions.
Being dropped from the mempool means that the node no longer keeps the transaction in its mempool.

When we say bitcoin transactions are irreverisble, we are talking about confirmed transactions. If a transaction is unconfirmed, it hasn't been included in the blockchain at all.


That's exactly why you shouldn't accept an unconfirmed transaction, if you don't trust the sender. There is no guarantee that an unconfirmed transaction will be finally confirmed.

What do you mean by transaction being able to drop from the mempool. You mean drop back to the sender? If yes, can this be called transaction reversal?
If yes , how about the bitcoin was used to purchase goods and the buyer has gone with the goods?

I just went through their FAQ centre as well to find anything about the pending transaction for too long but unfortunately there is no article related to that and also no ques about the transaction will be rebroadcasted if it dropped from the mempool so now all comes to a narrow path which is just wait and contact the support team to do anything about it.

But usually the support team will take 7 to 10 days to give an actual reply for a support ticket in coinbase platform that really sucks and as said its another lesson whynwe have to choose a wallet which gives complete control to us.

The default in Bitcoin Core is 2 weeks but it's configurable so it may take more time than that for the whole network to forget your transaction.

Coinbase may also have a system that re-broadcasts transactions the moment it's dropped from their node's mempool.
But since they are custodial and closed-source, there's no way of confirming that.

What about how long usually it takes to mempool gonna drop transactions with low fees like this

No one can certainly say that. Right now, the fee is 31 sats/byte. It may take few more days/weeks to get the fee minimized to your. Avoid centralized/third party wallets to make sure you can set your own fee, bump the fee and also, you can use CPFP when necessary.
Follow mempool.space to know when fee will be lowered.

The combined fee rate of your transaction and its unconfirmed parents is 14.1 sats/vbyte. This puts you around 33 MvB from the tip of the mempool at present. It's been over 3 weeks since we last processed transaction at this fee, and given the way the mempool is behaving right now, that's not going to change any time soon. Ordinarily when waiting this long the transaction would simply be dropped from the mempool and you would be free to make another transaction with a better fee, but Coinbase seem to have rebroadcast it after it was dropped. You could be waiting weeks unfortunately.

Any ETA for it sir i mean how long usually it takes

Coinbase can't/won't fix it.

The two unconfirmed parents in OP's transaction are both not opted in to RBF, so they cannot be replaced via that. Further, they are both huge transactions, with weights of 19.4 kvB and 20.04 kvB respectively. Given the current fees already paid by the three unconfirmed transactions, to get the combined fee up to around 40 sats/vbyte any CPFP transaction would have to pay over a million sats in fees.

OP is simply going to be stuck until the mempool clears out to 14 sats/vbyte. Another strong argument for not using third party wallets where you cannot set your own fees.

You have no choice then. You can try contacting coinbase to check this once again or you can try some paid/free accelerator service. There were a few free accelerator service in the forum but can't see them now anymore.

Edit- Since your tx has unconfirmed parent tx, Coinbase should fix it.

I know but I mixed up sat/byte vs sat/vbyte lol.

I used my binance wallet to recieve it sir also viabtc asks 10k dollars to solve that problem

For using ViaBTC free accelerator, the fee rate must be equal or greater than 10 sat/byte. The fee rate used for OP's transaction is around 8.8 sat/byte.
The other problem is that the transaction in question has unconfirmed parents and their free service doesn't accelerate such transactions.