Why can a Bitcoin transaction stay unconfirmed even with a higher fee?

[WhoYouCantKill]

It depends on the urgency you want just to get your funds immediately, base on my experience, before I used to see the price for the low priority to mempool ranging before like 20$ but apparently right now I do always seen here like around 5 sat/byte as a higher priority, I do rarely use the RBF but instead just checking when the market traders are active so at least I cannot be part of those transactions stuck because of congestion. Instead I prefer to wait as long as the txid generated there is no problem with that well just if you will send bitcoin to buy a services most of them require at least 1 confirmation.

We need to understand that the cheapest transactions ain’t always the most convenient ones. If the bitcoin you’re sending is for a time sensitive payment, there’s really no point waiting for fees to drop because that could create a completely different problem, especially when the recipient needs confirmation Asap. One way to avoid rushing the transaction later on is to first understand the recipient’s confirmation requirements first before proceeding with your payment, because this is basically what give you the best idea on the amount of fee to use for that particular transaction.

[hadesdex]

The CPFP conditions mentioned earlier in the thread are worth spelling out, since that is where people get stuck. CPFP only works if the stuck transaction paid one of your own addresses, and that unconfirmed output has to be large enough to carry the child transaction spending it — the child needs a fee that covers both transactions' combined size at the fee rate you are targeting. If the stuck output is small, or it went to an exchange deposit address, you cannot CPFP it and your options shrink to RBF or waiting out the mempool.

That is also why the RBF caveat upthread matters in practice. A replacement gets a new txid, and services that follow the first-seen txid (exchanges crediting deposits, payment processors) can silently stop tracking it, so you end up opening a support ticket instead.

My order of preference: enable RBF at broadcast time if the wallet offers it, check the fee rate against a mempool estimator before sending rather than after, and consolidate small UTXOs while fees are low so future transactions are small in vBytes and cheap to bump.

[Charles-Tim]

The CPFP conditions mentioned earlier in the thread are worth spelling out, since that is where people get stuck. CPFP only works if the stuck transaction paid one of your own addresses, and that unconfirmed output has to be large enough to carry the child transaction spending it — the child needs a fee that covers both transactions' combined size at the fee rate you are targeting. If the stuck output is small, or it went to an exchange deposit address, you cannot CPFP it and your options shrink to RBF or waiting out the mempool.

Child-pay-for-parent does not only necessarily mean the receiver have to spend part of the coins of the unconfirmed transaction. If the unconfirmed transaction has change address, the sender can also use the coins of the change address for the child-pay-for-parent. But if the sender send all and no coin sent to change address, the receiver have to be the one to do the child-pay-for-parent. But with how most bitcoin wallet are supporting replace-by-fee, that is enough for not to waste bitcoin on another transaction.

[Bitcoin Smith]

The CPFP conditions mentioned earlier in the thread are worth spelling out, since that is where people get stuck. CPFP only works if the stuck transaction paid one of your own addresses, and that unconfirmed output has to be large enough to carry the child transaction spending it — the child needs a fee that covers both transactions' combined size at the fee rate you are targeting. If the stuck output is small, or it went to an exchange deposit address, you cannot CPFP it and your options shrink to RBF or waiting out the mempool.

Child-pay-for-parent does not only necessarily mean the receiver have to spend part of the coins of the unconfirmed transaction. If the unconfirmed transaction has change address, the sender can also use the coins of the change address for the child-pay-for-parent. But if the sender send all and no coin sent to change address, the receiver have to be the one to do the child-pay-for-parent. But with how most bitcoin wallet are supporting replace-by-fee, that is enough for not to waste bitcoin on another transaction.

I just learned that even a sender can do the CPFP and that is entirely different from bump fee or so-called RBF, thanks for teaching me about this and probably for others too. And if a sender pays for the parent tx here then they can't use other UTXOs right, it must be from the same one in that transaction?

[hosemary]

And if a sender pays for the parent tx here then they can't use other UTXOs right, it must be from the same one in that transaction?

What do you mean by other UTXOs?
It's simple. CPFP can be done by anyone who has control over any of the outputs.

If you make a transaction and your transaction has a change, you have control over the change output and you can do CPFP.

[Charles-Tim]

And if a sender pays for the parent tx here then they can't use other UTXOs right, it must be from the same one in that transaction?

I think you have been answered.

Example is If you use 0.001 BTC UTXO for a transaction which will later be the parent transaction, and it has a change of 0.0002 BTC sent to change address which is another UTXO that is yet unconfirmed. You can send part or all of the 0.0002 BTC as the child transaction. If the 0.0002 BTC is not enough for the new (which will be the child) transaction, like you want to send it to someone, you can add other UTXO or UTXOs (which is not or are not part of the coins of the parent transaction) with the 0.0002 BTC which is a change from the parent transaction to do the child-pay-for-parent.

In short, just make sure the child transaction has part of the coins sent to the change address. If you like, you can spend part of it, all of it, or add more coins which are not part of the change address to it.

[Sticky Bomb]

For instance, a higher amount of transaction could have a lower fee rate than a smaller amount of transactions even though the fees are higher.

This depends on the number of inputs and outputs which contributes to the size of the transaction, a higher amount transaction with a lesser inputs and outputs would be cheaper than a smaller amount transaction which has more inputs and/or outputs.

Do you typically use RBF to offer a higher fee for transactions if they take longer to become confirmed or do you just wait for a transaction to get confirmed?

It is best to make sure that the RBF does not lead to the transaction failing, as some services follow the first TXID, and if the RBF is used, it may lead to stopping the processing of the transaction as it will become invalid, and then you will need to contact the support team to update your balance.

When you say services, do you mean non-custodial wallets? Could you please share the services in this category. I've done RBF several times with Electrum with no problem. My thought are that since they are broadcasted on the mempool, the transaction the miner selects first into a block that gets confirmed would be valid, or are there some limitations to this as regarding the first TXID stuff?

[hosemary]

It is best to make sure that the RBF does not lead to the transaction failing, as some services follow the first TXID, and if the RBF is used, it may lead to stopping the processing of the transaction as it will become invalid, and then you will need to contact the support team to update your balance.

When you say services, do you mean non-custodial wallets? Could you please share the services in this category. I've done RBF several times with Electrum with no problem. My thought are that since they are broadcasted on the mempool, the transaction the miner selects first into a block that gets confirmed would be valid, or are there some limitations to this as regarding the first TXID stuff?

hugeblack meant custodial services like instant exchanges which provide one-time deposit addresses.

The potential issue mentioned by hugeblack happened to me once before.
I made a deposit into an instant exchange, and they recorded my deposit. I bumped the fee to make the transaction confirmed faster. This made the original transaction invalid, and they didn't process the payment. I remember the issue was resolved after I contacted their support.

[Bitcoin Smith]

And if a sender pays for the parent tx here then they can't use other UTXOs right, it must be from the same one in that transaction?

I think you have been answered.

Example is If you use 0.001 BTC UTXO for a transaction which will later be the parent transaction, and it has a change of 0.0002 BTC sent to change address which is another UTXO that is yet unconfirmed. You can send part or all of the 0.0002 BTC as the child transaction. If the 0.0002 BTC is not enough for the new (which will be the child) transaction, like you want to send it to someone, you can add other UTXO or UTXOs (which is not or are not part of the coins of the parent transaction) with the 0.0002 BTC which is a change from the parent transaction to do the child-pay-for-parent.

In short, just make sure the child transaction has part of the coins sent to the change address. If you like, you can spend part of it, all of it, or add more coins which are not part of the change address to it.

This is what I am asking, like if I have UTXOs of X,Y and Z and the transaction had X and Y as input with some change but as a sender can increase the fee then he can also add the Z UTXO as part of the same transaction. Based on the your reply it is possible but when we do that then the same TXID will remain while adding a new UTXO to pay for the fee right?

[Charles-Tim]

Based on the your reply it is possible but when we do that then the same TXID will remain while adding a new UTXO to pay for the fee right?

Yes.

On all child-pay-for-parent transactions, no txid replaced, unlike replace-by-fee.

[hosemary]

This is what I am asking, like if I have UTXOs of X,Y and Z and the transaction had X and Y as input with some change but as a sender can increase the fee then he can also add the Z UTXO as part of the same transaction. Based on the your reply it is possible but when we do that then the same TXID will remain while adding a new UTXO to pay for the fee right?

What matters is that the second transaction (the one you make to increase the combined fee rate) spends an output of the first transaction.
If the first transaction has a change and you have control over it, you can spend the change UTXO along with any other coin you own (like Z) in the second transaction to do CPFP.