Is it possible to cancel a transaction with false RBF?

[davidjjones]

Hi everyone
I want to know that if I set replace-by-fee to false in a transaction, is it possible to cancel it or no?

[1715042264]

1715042264

[1715042264]

1715042264

[1715042264]

1715042264

[ranochigo]

Yes. Transactions can be replaced until they get into a block, for which the difficulty of it increases exponentially. It is far easier for someone to RBF a transaction with opt-in RBF flag, but it doesn't mean that the transaction without the flag would be safe. Miners can (un)intentionally include a separate transaction from the one that you expect to confirm.

That being said, most of the time, you would either need the participation of the miner before the transaction gets into a block. Sending a replacement which spends at least one of the inputs of another non-RBF transaction that hasn't confirmed yet would result in a poor propagation, and a smaller chance for a miner to see and include it into their block.

[LoyceV]

If the required fee stays above the fee for your transaction, it will drop from mempool eventually (unless your wallet keeps broadcasting the transaction). So it is possible, but currently fees are low.
It's also possible a miner will accept your double spend transaction, but most nodes don't accept it.

To be safe, you shouldn't accept a payment with 0 confirmations.

[HCP]

I want to know that if I set replace-by-fee to false in a transaction, is it possible to cancel it or no?

Depends on what you mean by "cancel"... there isn't really a way to "cancel" any valid bitcoin transaction. With "Replace-by-fee" (RBF), you're able to replace a transaction with another one with some certain caveats... like increasing the fee etc.

Without the RBF flag being set to true, then you would need to attempt a "classic" double-spend to replace the transaction. While it's not strictly impossible it can be quite difficult.

What is foundation for your question? Are you wanting to know if having RBF disabled offers some sort of guarantee?

[Charles-Tim]

I want to know that if I set replace-by-fee to false in a transaction, is it possible to cancel it or no?

Why not just make the transaction support RBF so you will be able to cancel the transaction or used it to increase the fee when needed to make the transaction replaceable?

Even transaction that does not support RBF should be confirmed (at least 1 confirmation) before you should accept it as a successful transaction.

Just as LoyceV commented, transaction can be dropped from mempool, but this can be frustrating and maybe nearly impossible, there was a time I have unconfirmed transaction for over 3 months this year when the mempool was congested, my wallet did not connect online for over a month but the transaction was not dropped, I was unable to rebroadcast the transaction, so this can be frustrating.

Also do not be surprised that a transaction you thought to have been dropped from mempool to still get confirmed as few nodes might still broadcast it to other few nodes.

[davidjjones]

Thanks for all replies 🙏
I am somewhat new to bitcoin. so I have to ask my question more clearly:
If someone has hacked my wallet and has the private keys, can he replace my transaction (non RBF) before confirmation?

[hosseinimr93]

If someone has hacked my wallet and has the private keys, can he replace my transaction (non RBF) before confirmation?

The hacker can make a new transaction including same input(s). It's very unlikely that a  miner includes the new transaction in a block, but that's possible.
Nodes usually reject a transaction including UTXOs that have already been spent in a non-RBF transaction even if the original transaction is still unconfirmed.

[sheenshane]

.. I have unconfirmed transaction for over 3 months this year when the mempool was congested, my wallet did not connect online for over a month but the transaction was not dropped, I was unable to rebroadcast the transaction, so this can be frustrating.

I never heard stuck transactions take over 3 months before it's to be confirmed due to the low fee and AFAIK, it's only 14-21 days estimated time that your transaction will be rejected or drop on the network and return to the wallet sender.  I think this experience is too much and it was already got confirmed earlier than 3 months but since you didn't online for 1 month.  It's a rare case when your transaction gets rejected and return to your wallet, eventually, it will always get confirmed after at least 2 weeks or more.

As long as it is 0 confirmation, there's a chance the transaction to be canceled.  Always priority by the miners to be accepted are those higher fees if you will double send transactions.

[hosseinimr93]

Always priority by the miners to be accepted are those higher fees if you will double send transactions.

Not always. Miners prioritize the transaction paying a higher fee, only if the transaction broadcast earlier has been flagged as RBF.    

In the case there are two unconfirmed transactions with same input(s) and the original transaction (the one made earlier) hasn't been flagged as RBF, the original transaction is likely the one that will be confirmed. (It's possible that the transaction made later will be confirmed, but that's very unlikely)
If the original transaction has been flagged as RBF, miners will probably pick the replacing transaction. (It's possible that the original transaction gets confirmed, but that's very unlikely).

[ranochigo]

If someone has hacked my wallet and has the private keys, can he replace my transaction (non RBF) before confirmation?

It depends. As I explained before, the point behind this would be to look at the transaction that would be included in a block in the chain first. If the transaction that gets included first is your transaction, there is nothing a hacker can do, and vice versa. What a non-RBF transaction basically means is that nodes will not relay transactions that spends an inputs of another, without the opt-in RBF flag. In layman's term, miners are probably not going to see it.

Of course, there exists certain circumstances which this wouldn't be true. If a miner has seen that transaction and agreed to include it in their block, they can do so provided that your transaction hasn't been confirmed yet. There has been cases whereby miners have included transactions with a lower fee or non-RBF replacement transactions. They are few and far between though.

Tl;dr: Yes, it is possible albeit more difficult.

[davidjjones]

As I understood from your explanations there is no way to guarantee my transaction but a potential hacker also has little chance to replace the TX.
What about the following methods?
1. Setting the highest TX fee
2. CPFP fee bumping by the receiver

[LoyceV]

If someone has hacked my wallet and has the private keys, can he replace my transaction (non RBF) before confirmation?

If someone has your private keys, he won't wait for you to make a transaction. He'll just sweep your coins with a high fee, without RBF. There would be nothing you can do to stop it.
So long story short: keep your wallet secure.

[hosseinimr93]

2. CPFP fee bumping by the receiver

In my opinion, this is a good idea especially if the network is congested.
Assuming the network is very congested and the original transaction has a very low fee, there's the possibility that your transaction drops from the mempool due to the limit size of 300 MB. If that happens, the hacker won't have any difficulty to broadcast a new transaction.
If you implement CPFP and increase the effective fee, you can make the hacker's work more difficult.

Also note that CPFP can be implemented by the sender if there's a change in the transaction.

[davidjjones]

If someone has your private keys, he won't wait for you to make a transaction. He'll just sweep your coins with a high fee, without RBF. There would be nothing you can do to stop it.
So long story short: keep your wallet secure.

I know that a hacker won't wait for me if he has the private key!
The situation I imagined: the private key has stolen from my hot wallet just before the transaction and the hacker has a chance to replace the tx before a confirmation.

[davidjjones]

In my opinion, this is a good idea especially if the network is congested.
Assuming the network is very congested and the original transaction has a very low fee, there's the possibility that your transaction drops from the mempool due to the limit size of 300 MB. If that happens, the hacker won't have any difficulty to broadcast a new transaction.
If you implement CPFP and increase the effective fee, you can make the hacker's work more difficult.

Also note that CPFP can be implemented by the sender if there's a change in the transaction.

Thanks for your full explanation

[o_e_l_e_o]

1. Setting the highest TX fee

If you set a fee which is sufficiently higher to mean your transaction gets confirmed in an earlier block than it would have done with a lower fee, then yes, you make the attacker's life more difficult since they have less time to try to replace your transaction and convince a miner to prioritize it. This is unlikely to make a difference if the change is from being confirmed in 2 blocks to being confirmed in 1 block, but if the change is the difference between 1 week and 1 block, then it becomes potentially significant. If 1 sat/vbyte will get you in the next block and you pay 100 sat/vbyte, then you don't really make things any harder for the attacker. It might be more expensive for them, but since it is your money they are stealing and spending, then it won't really be a disincentive for them.

2. CPFP fee bumping by the receiver

As above. If you can bump the fee sufficiently to get a much earlier confirmation, then it will be much more difficult for the attacker.

[odolvlobo]

Sorry for being the Nth person to answer the question.

Miners and nodes are not required to honor the RBF flag, but it is assumed that most do. Furthermore, if the second transaction is broadcast very soon after the first, the second transaction might be received by some miners first, giving the second transaction a chance to be confirmed instead of the first.

So, attempting to spend the inputs of an existing unconfirmed transaction with RBF disabled by paying higher fees or using CPFP is normally unlikely to succeed, but it is not impossible.

[aliashraf]

One point to be noted regarding RBF flag:

It is not part of Bitcoin's consensus framework, just an implementation specific trick present in bitcoin client code, node operators are free to patch this code such that the RBF flag is not visited by their clients at all while they are replacing txns by their high-fee alternatives if any, forwarding the new ones as well, still remaining fully synchronized with other peers.