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?

Improve this question
1
  • 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
    Commented Sep 9, 2012 at 18:56

2 Answers 2

Reset to default
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.

Improve this answer
8
  • 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
    Commented Aug 21, 2012 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
    Commented Aug 21, 2012 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
    Commented Aug 22, 2012 at 1:58
  • If the second transaction has a higher fee, the chances of it getting accepted are high.
    – Jus12
    Commented Feb 6, 2013 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'.
    Commented Apr 9, 2013 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

Improve this answer
2
  • does this work for non wallet id transactions in any way ?
    – Shabahat M. Ayubi
    Commented Jun 2, 2017 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
    Commented Dec 11, 2017 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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