Cancelling unconfirmed transactions

[DeathAndTaxes]

No a transaction is just that a transaction.
A confirmed transaction is one which is recorded in a block.
An unconfirmed transaction is one which is in the memory pool.

Bitcoin was never intended to allow cancelling transactions.  It can be done by hacking the wallet file and waiting for the transaction to be removed from the memory pool but that isn't made easy due to the likelihood that it would cause even more user confusion/chaos.  For example you could "cancel" a transaction and it could end up in a a block as your "cancellation" is only local.  You can't control what other nodes do.  Also your client may not be up to date due to a delay or protocol issue.  The client may report a transaction as cancellable when in reality it was confirmed in a block hours (or even years ago).

Is the behaviour of the memory pool deterministic?

Yes.

[1714799189]

1714799189

[1714799189]

1714799189

[Peter Todd]

I thought I have seen Gavin somewhere talking about adding fees to already existing transactions... am I mistaken ?

I'm working on a patch that will create the basic infrastructure to add fees to transactions that have been sent but not yet included in a block. It will only let you add additional inputs and outputs, but never make any output have a lower value than it did before. Nor will it let you modify a transaction that has already been spent.

Unfortunately this kind of thing takes quite awhile to get implemented due to all the careful testing required. Expect a few months before it is usable.

[deepceleron]

I thought I have seen Gavin somewhere talking about adding fees to already existing transactions... am I mistaken ?

I'm working on a patch that will create the basic infrastructure to add fees to transactions that have been sent but not yet included in a block. It will only let you add additional inputs and outputs, but never make any output have a lower value than it did before. Nor will it let you modify a transaction that has already been spent.

I've been considering what criteria nodes should have to allow discarding a pending in-memory transaction and replace it with an increased-fee transaction. Your conclusion is logical.

Since the output of a transaction that is change can't be identified by miners or nodes, to validate what constitutes a legitimate non-double-spend transaction, it appears that a retransmitted transaction must not alter any inputs or outputs in the original transaction. If one of the outputs were allowed to be reduced to increase the fee, this could mean a 0 confirmation payment to someone could be changed from the expected value, which is the definition of a malevolent double-spend. If any output could be modified in the original, this means that 0 confirm payments could not be trustable, because output values could be moved from one recipient to another or reduced.

Instead, fee must solely be added by adding a new input, and a separate change payment must be sent. In the example below, I show where we add another complete input and change (where fee = input - change).



OutputX, another payment to another recipient (or a third change payment to enhance anonymity even more), could be optional and shouldn't be a "blocker" if it exists. Change from adding a fee demands some new outputs. However, being able to add such "mini-transaction" chunks with new inputs and outputs and retransmit them, could mean that a service that issues many regular payments could just keep adding to an existing 0 confirmation transaction and retransmitting, instead of creating a new transaction. I don't know if this would be a novel feature or undesirable.

Another strange situation is if the original tx has spent all the available inputs, the user can't increase the fee. Explaining why the wallet can't add more fee even though it shows a balance will be one for the UI designers.

[Sukrim]

On one hand bitcoin's network structure + code is not the smartest one around and relies on flooding, so sending the same thing in different versions might cause even more problems.

On the other hand memory is even more expensive and probably limited amongst nodes than storage capacity for blocks. Bitcoin-qt already takes up ~half a GB of RAM on my machine, if it then has to store multiple versions of each transaction someone decides to publish it might get out of hand quickly. This stuff is not specified by the way and doesn't really influence the way blocks are built, so you can create your own client with a smarter netcode + multiple versions of the same transaction. Bitcoin-qt will probably not like your client, as it will be viewed as potential double-spender (or at least trying to cheat somehow), but as long as you manage to get these transactions to miners, I don't really see a problem that this cannot be done.

I would advise against it however, as there is little benefit to having multiple versions vs. updating one version, especially since in the end only one single version will be included anyways.

[Peter Todd]

Re: retep & deepceleron,
Why promote bad usage habits in the first place?

I'm a pragmatist. If I wrote a patch that replaced transactions with any newer one if the total fees were increased, it would never get into the reference client.

On a conceptual level I see no problem with spamming the memory pool with multiple versions of the same transaction. Obviously the first one to get included in a block makes all the others invalid -- but why is that such a problem?

As an aside you must require a limited resource to be expended to broadcast a transaction on the network for DoS protection. This also implies that the network bandwidth required to run a full node will now be an even further higher multiple of the "blockchain bandwidth" than it already is. How to price that properly is an open question.

[k3t3r]

Most of this topic is beyond the scope of my understanding. Is there any simple instructions how to get my unconfirmed transaction confirmed?

[D35TR0Y3R]

Hi

As far as I am aware it is not possible to cancel unconfirmed transactions currently.  If the block limit is maintained, this will likely lead to a scenario where first transactions without fees will go through in calmer moments, then not at all anymore. 
I was now thinking of the following scenario: somebody tries to be a cheapass by not adding a fee to his transaction, transaction volume picks up forever, and the transaction is stuck in limbo forever.  He might try a new doublespend with fee, but apparently that is not trivial either? 
Would it be good to implement a "cancel unconfirmed transaction" option in the clients?  Or does this already exist and is my information outdated?

I just did that same thing, because Im an idiot. I'm using blockchain.info's online wallet, but I can get the private key and run it off the bitcoin client locally. Can someone explain to me what would stop me from "double spending" the coins that are stuck in limbo, and would it actually be "double spending"?

[deepceleron]

Hi

As far as I am aware it is not possible to cancel unconfirmed transactions currently.  If the block limit is maintained, this will likely lead to a scenario where first transactions without fees will go through in calmer moments, then not at all anymore.  
I was now thinking of the following scenario: somebody tries to be a cheapass by not adding a fee to his transaction, transaction volume picks up forever, and the transaction is stuck in limbo forever.  He might try a new doublespend with fee, but apparently that is not trivial either?  
Would it be good to implement a "cancel unconfirmed transaction" option in the clients?  Or does this already exist and is my information outdated?

I just did that same thing, because Im an idiot. I'm using blockchain.info's online wallet, but I can get the private key and run it off the bitcoin client locally. Can someone explain to me what would stop me from "double spending" the coins that are stuck in limbo, and would it actually be "double spending"?

If the transaction was sent with no fee when a minimum was required, the rebroadcast one with adequate fees (something more than the minimum) will probably go right through. There is no guarantee that it will use the same input payments and actually double-spend, unless you have a very minimal receiving history or send your entire balance. Note that this will make your Bitcoin-qt wallet your new wallet, as it will be the only one that has the change transaction, Bitcoin contains multiple addresses and doesn't reuse them.

[Stn]

One should determine between unconfirmed transaction and unbroadcasted transaction (what blablahblah was trying to say). Both look similar in the transaction list of Bitcoin client. But first has information in the chain already and latter doesn't.

It is up to client implementation. Satoshi client allows unbroadcasted transactions in it's internal pool (and by the way takes long time before attempt to re-broadcast it again). Other clients just don't even hold such transaction. They either broadcast them successfully or reject.

So unconfirmed transaction are not to be taken out of the chain. But unbroadcasted transaction are removable from the client queue (though with some third party software, Satoshi client doesn't have such functionality out of the box).

[deepceleron]

One should determine between unconfirmed transaction and unbroadcasted transaction (what blablahblah was trying to say). Both look similar in the transaction list of Bitcoin client. But first has information in the chain already and latter doesn't.

It is up to client implementation. Satoshi client allows unbroadcasted transactions in it's internal pool (and by the way takes long time before attempt to re-broadcast it again). Other clients just don't even hold such transaction. They either broadcast them successfully or reject.

So unconfirmed transaction are not to be taken out of the chain. But unbroadcasted transaction are removable from the client queue (though with some third party software, Satoshi client doesn't have such functionality out of the box).

There is no "unbroadcasted" transaction, except when you haven't press the send button yet. However a transaction that does not include at least the minimum relay fee (currently 0.0001 BTC/kB) will not be communicated through the network to others by 99% of the Bitcoin nodes or recognized by miners, making it's timely inclusion in the blockchain even less likely. A replacement transaction that does include the required fee will be the one that is used, because it is not considered a double-spend by everybody that ignored the first one.

[jackjack]

You can delete transactions from your wallet
You can also export all your private keys to a CSV file, then import them all in a clean wallet
Both can be done by pywallet

[blablahblah]

Hi

As far as I am aware it is not possible to cancel unconfirmed transactions currently.  If the block limit is maintained, this will likely lead to a scenario where first transactions without fees will go through in calmer moments, then not at all anymore.  
I was now thinking of the following scenario: somebody tries to be a cheapass by not adding a fee to his transaction, transaction volume picks up forever, and the transaction is stuck in limbo forever.  He might try a new doublespend with fee, but apparently that is not trivial either?  
Would it be good to implement a "cancel unconfirmed transaction" option in the clients?  Or does this already exist and is my information outdated?

I just did that same thing, because Im an idiot. I'm using blockchain.info's online wallet, but I can get the private key and run it off the bitcoin client locally. Can someone explain to me what would stop me from "double spending" the coins that are stuck in limbo, and would it actually be "double spending"?

I'm sure none of it's "double spending". AFAIK real double spending is when you get your transactions fraudulently confirmed in 2 different places in a block because of a continuous 51% attack. Or when you pay for something, get the transaction confirmed X times, but then the blocks get orphaned because of ad-hoc network crappyness/man-in-the-middle exploits/51% attack so you're able to "re-spend" the coins elsewhere.

My view is that the memory pool is just a queue with zero guarantees, and it should be treated that way! It should not be used as a checking/IOU system. Having pending transactions stuck indefinitely and being forced to use 3rd party software sucks balls. The system should be improved so that:

• Sending the same transaction multiple times but with different fees is standard practice. No need to treat the first attempt like it's sacred .
• Harden the memory queue against spamming, and do it properly. How do website or email systems do it? How about: for each request, send a small proof-of-work problem for the wallet software to solve? That way it's like a small fee.
• Get some pricing visibility. Confirmation delay vs fee generosity needs to be graphed and put on a website somewhere, or even embedded in the wallet software.

[Stn]

There is no "unbroadcasted" transaction, except when you haven't press the send button yet.

It is not necessary that transaction will be broadcasted at first attempt even if you press send button. Easy to reproduce. Take Satoshi client. Disconnect network. Send some bitcoins. See it appear in transaction list. It is unbroadcasted transaction. And it has same grey "?" sign as 0 conf transaction.

This behavior is client dependent. Other clients (i.e. Electrum) do not queue transactions but instead bounce it if broadcasting was unsuccessful.

[btc4ever]

This just happened to me.  ( Using primecoin-qt, but I expect it applies to bitcoin-qt also. )   My network went offline and I didn't realize it before I made a payment to another wallet of mine.  When the network came back, the wallet synced with the network, but the status stayed 0/offline.  After 10 minutes or so, I restarted the QT wallet with -rescan option.  Now it says status is Unconfirmed, which suggests to me that the client thinks it has been broadcast.  However, my receiving wallet does not see the transaction when I use listtransactions.  and it has been at least 30 minutes now.

Fortunately I was sending a small amount, and I know I can export/import if need be...  and I guess there is some chance it will fix itself with time, but I could see how this could really bite a non-technical person hard.

And it is not an uncommon situation.... really easy to get into actually.

If "cancel transaction" is not an option, then it seems to me that the client should not allow offline sending.

Or a "rebroadcast transaction" option.   Or at the very least a "will retry again in 60 seconds" tip text.

Right now, the messaging is useless, and the transaction is very clearly stuck.

It is not necessary that transaction will be broadcasted at first attempt even if you press send button. Easy to reproduce. Take Satoshi client. Disconnect network. Send some bitcoins. See it appear in transaction list. It is unbroadcasted transaction. And it has same grey "?" sign as 0 conf transaction.

This behavior is client dependent. Other clients (i.e. Electrum) do not queue transactions but instead bounce it if broadcasting was unsuccessful.

[btc4ever]

Update:  the transaction finally arrived while i was typing the above post.  Still, it took a good 45 minutes instead of the expected < 5 seconds to appear in the destination wallet.  And the messaging in the client is useless at that point as it gives no indication of retries or what is going on with the transaction.

[Stn]

In my case it happened several times even the client was online. Either network was too busy or whatever else but transaction stuck for hours. Receiver was going mad because he though I was lying. And it was not petty money. Even I would like to re-send from another place I was bound to that hung transaction which can dispatch any moment or stay frozen for longer.

There is good technical logic behind asynchronous behavior in many programs. But here it is proven fault of this pattern. Developers should take action.

[Stephen Gornick]

Still, it took a good 45 minutes instead of the expected < 5 seconds to appear in the destination wallet.

That's normal (and desired) behavior.

If you want to force a re-broadcast to occur on-demand:
 - http://en.bitcoin.it/wiki/Raw_Transactions#Re-broadcast_a_transaction

[Stn]

That's normal (and desired) behavior.

I wonder to whom else (except you) it could be normal and desired to wait hours before program deigns to broadcast a transaction? Attempt on every other minute must be backbreaking effort for the said program.

[kjj]

That's normal (and desired) behavior.

I wonder to whom else (except you) it could be normal and desired to wait hours before program deigns to broadcast a transaction? Attempt on every other minute must be backbreaking effort for the said program.

Don't ever confuse "good for the network" with "good for me".

[Stn]

Bloody client program holds my funds neither bouncing them back nor pushing to the network acting as The Dog in the Manger. Which part of this is good for the network?