21

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?

Murch
  • 75,206
  • 34
  • 186
  • 622
Steven Roose
  • 11,841
  • 8
  • 45
  • 73
  • 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 Sep 09 '12 at 18:56

2 Answers2

13

Bitcoin-Qt doesn't support anything like that.

Theoretically:

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.

theymos
  • 8,994
  • 42
  • 37
  • 1
    What's the point of marking a transaction non-final, then? A lot of what's at https://en.bitcoin.it/wiki/Contracts seems to require replacing transactions which were marked non-final. – Daniel H Aug 21 '12 at 21:11
  • @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 Aug 21 '12 at 22:20
  • 2
    At 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 Aug 22 '12 at 01:58
  • If the second transaction has a higher fee, the chances of it getting accepted are high. – Jus12 Feb 06 '13 at 13:28
  • @Jus12 {{citation needed}} – o0'. Apr 08 '13 at 15:36
  • @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 Apr 08 '13 at 23:31
  • 1
    @Jus12 it would be more advantageous, but AFAIK no miner actually does that, hence your sentence is wrong. Until you prove otherwise. – o0'. Apr 09 '13 at 08:20
  • 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 Nov 12 '17 at 09:37
4

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

Tanguy
  • 141
  • 2
  • does this work for non wallet id transactions in any way ? – Shabahat M. Ayubi Jun 02 '17 at 17:17
  • @ShabahatM.Ayubi only with in-wallet transactions https://bitcoin.org/en/developer-reference#abandontransaction 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 Dec 11 '17 at 13:45