Topic: Cancelling unconfirmed transactions - page 2. (Read 21122 times)

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.

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

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.

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).

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.

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"?

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

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.


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.

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.

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.

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.

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).

Yes.

Since the wallet has no provision to delete transactions, what you can do is export the keys, create a new wallet and import the keys.  Voila, your funds are spendable once again.

It was an accidental double-spend attempt. But because most of it had already been spent, it won't verify... leaving the remainder in limbo.

If it is a low priority tx the "anti-spam" fee is mandatory.  Without the fee most nodes won't even relay the tx much less include it in a block.  It is a denial of service prevention mechanism.

Now how can that be?

Can you resend it with a fee?

Even without a fee, surely it should have gone through by now?

I have an unconfirmed transaction from October. 

It isn't just the duration, it is space in the memory pool.  As that space fills up, older transactions get bumped out.

How long time does bitcoind remember a transaction?

Amazing that this hasn't been discussed in detail before.

Such a basic feature. I guess it must be because fees have never been much of an issue before.