20

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?

  • 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 9 '12 at 18:56
12

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.

  • 1
    What's the point of marking a transaction non-final, then? A lot of what's at 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 1:58
  • If the second transaction has a higher fee, the chances of it getting accepted are high. – Jus12 Feb 6 '13 at 13:28
  • 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 9 '13 at 8:20
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

  • does this work for non wallet id transactions in any way ? – Shabahat M. Ayubi Jun 2 '17 at 17:17
  • @ShabahatM.Ayubi only with in-wallet transactions 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.