Topic: Cancelling unconfirmed transactions (Read 21112 times)

Here is the status of my work on tx replacement: http://www.mail-archive.com/[email protected]/msg03126.html

That particular version is the "zeroconf safe" version that only lets you replace a transaction if all outputs are paid in the replacement with equal or greater value. I also wrote a pure replace-by-fee version months ago. What's left to be done is the hard and risky work of fixing the wallet code.

Note that John Dillon has offered 4BTC to whomever gets it done - if anyone wants to take on the wallet side of things it'd fix some outstanding issues and I think the effort would deserve 95% of the funds.

Unconfirmed wallet transactions are automatically rebroadcast by bitcoind/Bitcoin-QT until they are confirmed.

That's all well and good. But what about the user with zero IT knowledge? Problems have to be automatically taken care of for them by the wallet software as much as possible.


Are either of these closer to implementation?

- http://en.bitcoin.it/wiki/Raw_Transactions#Re-broadcast_a_transaction

Yes a Rebroadcast feature should b e added. There's no way to verify at least from what Im seeing if a QT is doing this.

I appreciate your reply it gives better sense. But still there is bad interface design. Compare with Electrum -- all connected peers failed to follow my transaction (rare thing but it happens). In 5 seconds client reports error and releases funds, allowing me to try to send again or use another wallet. Though "official" client keep funds in hostage for hours driving me mad as well as fund receiver. And it happened to me 3 or 4 times already.

I don't believe that during that hours in the background client trying hard to rebroadcast pseudo-randomly. If it doesn't go from the first attempt it will go on the second.

There is different behavior based on the client.

With Bitcoin-Qt/bitcoind, the client (if left running) will sporadically attempt to re-broadcast the transaction indefinitely.   If the reason it doesn't end up in a block is because it is a low-priority transaction and a fee wasn't paid then there is no solution other than to perform wallet surgery (using a tool like jack jack's pywallet utility) to delete the unusable transaction.  

The hybrid E-Wallet from Blockchain.info behaves differently.  It will eventually stop retrying (in about a day) and the transaction removed from the wallet, allowing the user to try to spend the fund again.

I'm not familiar enough with Multibit, Electrum and other clients to know their behavior.

As far as the ability to bump an existing transaction there have been two approaches, ... "parent pays for child" and "replace by fee", however neither is targeted for inclusion in any specific upcoming release.

I know there are good reasons but to the casual observer and user it does seem that Bitcoin is a bit rough-and-ready if transactions can get "stuck" in cyberspace and the sender can't do anything about it.

If transactions can't be easily cancelled while pending, could they have a user-defined expiry date-time at origination, with a default of, say, +24 hours? Then, any unconfirmed transactions beyond expiry are deleted from the pool. Wallets can also then re-credit the BTC to the sender, knowing the amount is not going to be processed, and the transaction could be done again with a higher fee.

There is no preset time limit.  The node psuedo-randomly rebroadcasts transactions.  Your node has no method of knowing if other nodes are still retaining a copy of your unconfirmed tx, only that a tx is self created and has been broadcast.  It broadcasts the tx, and then wait, if it sees the tx in a block it removes it from its memory pool.  When a self generated tx in its memory pool becomes stale it broadcasts it again.  It is possible peers already know of that tx however it doesn't check it simply broadcasts the tx and refreshes its status in its memory pool.

Spamming a tx to all nodes continually until they appear in a block would use up a lot of network resources and that could be exploited by an attacker as camouflage to create a denial of service attack.  In other words if "well behaved" nodes are spammy then it becomes harder to identify and ban truly malicious nodes.  As it is right now actual malicious are easy to spot and ban.

Bitcoin is an open source project.  The rebroadcast algorithm can be improved so feel free to do a pull (or bounty for a pull).
Keep in mind however that:
a) an node has no method of knowing if an arbitrary unconfirmed tx is in the memory pool of peers without asking
b) when a node drops a tx from its memory pool either on receipt (invalid tx or insufficient fee) or when memory pool is full it does not notify the sending node.
c) a node should rebroadcast tx to peers on random intervals to avoid giving away information (i.e. your node sends the same tx every 1 minute to all 8 peers an a malicious entity is two of your peers you have essentially identified yourself as the originator)
d) the volume of communication should not make it possible for a malicious node to use that as cover to spam the network.

One attempt per 45 minutes to avoid DDOS? You were kidding, right?

Actually the reason for the slow broadcasts is to not give away information on what coins are in your wallet.

Replace-by-fee  helps with privacy here actually as re-broadcasts would generally have fee increases and thus any node could have sent them.

It does rebroadcast just not at a rate which would be seen as a denial of service attack.

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?

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

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.

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

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.

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.

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.