Is it possible to cancel an unconfirmed transaction?



If you submit a transaction to the network but it hasn't yet be confirmed by a block, is it possible to cancel this transaction?

Steven Roose

Posted 2012-08-21T19:00:17.543

Reputation: 11 183

Is it not confirming because it is an invalid transaction (double-spend) or just low priority / spammy and thus could take a day or so? – Stephen Gornick – 2012-09-09T18:56:46.320



Bitcoin-Qt doesn't support anything like that.


A transaction is canceled by publishing a second transaction which double-spends some of the coins used in the first transaction (this can be a send-to-self). If the second transaction is included in a block before the first one, the first one becomes invalid and can be considered fully cancelled after the second transaction receives 6 confirmations. It's normally not easy to do this. Network nodes won't accept transactions which double-spend coins used in a transaction they already know about. However, nodes gradually forget about transactions if they don't get into blocks, so a transaction could be cancelled if it doesn't make it into a block after several days and both the sender and recipient stop rebroadcasting it.

Bitcoin used to have a feature called transaction replacement. A transaction could be marked as non-final, which prevented this transaction from getting into a block, but allowed the transaction to be cancelled at any time. Satoshi disabled this a while ago, though. Transactions can still be marked as non-final, but they can't be replaced.


Posted 2012-08-21T19:00:17.543

Reputation: 8 416

@Jus12 {{citation needed}} – o0'. – 2013-04-08T15:36:36.320

@Lohoris If you realize that a fee is a bid for a miner to accept transactions, and as the reward keeps decreasing, it is more advantageous for miners to drop a lower fee transaction from a double spend. – Jus12 – 2013-04-08T23:31:30.510

1@Jus12 it would be more advantageous, but AFAIK no miner actually does that, hence your sentence is wrong. Until you prove otherwise. – o0'. – 2013-04-09T08:20:22.520


What's the point of marking a transaction non-final, then? A lot of what's at seems to require replacing transactions which were marked non-final.

– Daniel H – 2012-08-21T21:11:55.353

@DanielH It should be possible to communicate non-final transactions privately and only broadcast the final version of the transaction. Currently, though, one of the parties can publicly broadcast a non-final transaction, and this non-final transaction can't be replaced by a later version of the transaction. This causes problems for some contracts. Nodes should probably just reject non-final transactions if they're not going to allow replacements. – theymos – 2012-08-21T22:20:18.857

2At present, for practical purposes, it's impossible to do this. In theory, miners should be happy to replace a transaction with a conflicting transaction with a higher fee. But to my knowledge, nobody implements this. The consensus seems to be that it's more valuable to the community to have unconfirmed transactions be more reliable. – David Schwartz – 2012-08-22T01:58:55.883

Do I properly understand that in case I've broadcasted the transaction of, for example, 1BTC with super low fee when the mempool is heavily loaded and my wallet, for example, has 10BTC - to cancel the first one, that is still unconfirmed, I need to send 10BTC to myself with normally high fee, so that 1BTC transaction will be out of place? – 0x49D1 – 2017-11-12T09:37:06.640

If the second transaction has a higher fee, the chances of it getting accepted are high. – Jus12 – 2013-02-06T13:28:54.873


From the help of the console :

abandontransaction "txid"

That will tag the transaction as abandonned

 "abandoned": true

After that, you can reselect the input(s) to send it with higher fees

Tested in bitcoin core 0.12.1


Posted 2012-08-21T19:00:17.543

Reputation: 141

does this work for non wallet id transactions in any way ? – Shabahat M. Ayubi – 2017-06-02T17:17:35.113

@ShabahatM.Ayubi only with in-wallet transactions The abandontransaction RPC marks an in-wallet transaction and all its in-wallet descendants as abandoned. This allows their inputs to be respent. Abandons the transaction on your node.

– 0x49D1 – 2017-12-11T13:45:22.317