reg. Unconfirmed transaction. What now?

[TheSwede75]

Sent this yesterday from my multibit wallet. What gives?
https://blockchain.info/tx/fd452d8d283aed52a6270a9d7bec849148fa42defbd23d17e4a798209514e918

[timeofmind]

Interesting. Could the transaction have been lost from all (relevent) miners' memory pools? If that was to happen, I guess you'd just have to send the transaction again.... but then how would you know that a miner out there may not write your first transaction sometime in the future? then you'd have inadvertently sent two transactions...

[TheSwede75]

Interesting. Could the transaction have been lost from all (relevent) miners' memory pools? If that was to happen, I guess you'd just have to send the transaction again.... but then how would you know that a miner out there may not write your first transaction sometime in the future? then you'd have inadvertently sent two transactions...

Yeah, it just seems.. well, really odd. Not a huge transaction by any means but still a little 'unnerving'.

[Remember remember the 5th of November]

You have a few very small outputs and a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.

[ct1aic]

Sent this yesterday from my multibit wallet. What gives?
https://blockchain.info/tx/fd452d8d283aed52a6270a9d7bec849148fa42defbd23d17e4a798209514e918

Greetings.

I already saw several times the message "Estimated Confirmation Time    Very Soon" and after some time, the verification counter started adding verifications... Perhaps you need to wait some more hours and next time, include a higher fee (0.0005 BTC for instance, instead of the MultiBit default value you added).

Summary
Size   1559 (bytes)
Received Time   2013-05-28 23:51:10
Estimated Confirmation Time    Very Soon
Relayed by IP   67.166.57.143 (whois)

[timeofmind]

If no miner accepts a transaction, and it eventually gets lost from miners' memory pools, it would be nice to be able to tell definitively that the transaction was declined... otherwise there is no way of knowing when the transaction might be included in the block chain at some future time... and no way of knowing when/if the transaction should be retried.

[timeofmind]

If no miner accepts a transaction, and it eventually gets lost from miners' memory pools, it would be nice to be able to tell definitively that the transaction was declined... otherwise there is no way of knowing when the transaction might be included in the block chain at some future time... and no way of knowing when/if the transaction should be retried.

Perhaps a policy in the protocol, if it is not included after a certain number of blocks... just drop it? So that we can be confident that it was dropped if so many blocks go by?

[DeathAndTaxes]

All nodes will drop a tx from the memory pool, however your node will continually (on a schedule) rebroadcast the tx to peers (who update their memory pool and relay it to other peers).

So you need to prevent your node from rebroadcasting the tx first.  That is tough as the client isn't designed to "undo" tx.  You need to manually edit the wallet to remove the offending transaction and then keep your node offline.  Eventually all other nodes will drop the transaction and you can respend the coins.

[tclo]

I've heard that if you don't add the miner's fee of .0005 or so, then it can take a week or so to confirm a transaction.

[Abdussamad]

You have a few very small outputs and a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.

How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee.

[tinus42]

I have a transaction of 0.000004 from 22 May which still has 0 confirmations. Yes it was from one of those faucets (stopped using them for more than a week). But it still won't get confirmed which is a bit sucky. These transactions should be either accepted after a short period or rejected and returned to sender.

[grue]

Actually, your transaction's priority is the sum of your inputs age multiplied by their value, then divided by the size of the transaction. As you can see in blockchain.info, your transaction contains many dust "inputs". Although many are from the same address, they still add to the size of the transaction. As a result, your transaction will have a small priority value. But if your transaction is small, and your inputs are old, they will get confirmed very quickly, even without a fee. For instance, my 1 input, 2 output transaction (~1.1 BTC value) was confirmed in the next block, without any transaction fees.

How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee.

but just because it's "standard" doesn't mean it bypasses the fundamental rule of fees: the higher fee per kb, and higher the priority, the more likely it's going to be included in a block. Keep in mind that if 13 cents in fees (0.001 BTC), your transaction will almost certainly be included in the next few blocks.

[Abdussamad]

Actually, your transaction's priority is the sum of your inputs age multiplied by their value, then divided by the size of the transaction. As you can see in blockchain.info, your transaction contains many dust "inputs". Although many are from the same address, they still add to the size of the transaction. As a result, your transaction will have a small priority value. But if your transaction is small, and your inputs are old, they will get confirmed very quickly, even without a fee. For instance, my 1 input, 2 output transaction (~1.1 BTC value) was confirmed in the next block, without any transaction fees.

How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee.

but just because it's "standard" doesn't mean it bypasses the fundamental rule of fees: the higher fee per kb, and higher the priority, the more likely it's going to be included in a block. Keep in mind that if 13 cents in fees (0.001 BTC), your transaction will almost certainly be included in the next few blocks.

Ok. Always good to learn more! More info about transaction priority in case anyone is interested:

https://en.bitcoin.it/wiki/Transaction_fees#Technical_info

[Mysticsam_3579]

It is very easy if the transaction is in blockchain.info then it is just to wait until it got confirmed. Thats it.

[DannyHamilton]

You have . . . a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.

How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee.

I believe the new "standard" fee is 0.001 BTC per kilobyte or fraction thereof.  Your transaction is larger than a kilobyte, therefore the fee should be 0.0002 BTC.  I'm not sure how many people have upgraded their nodes to use the new relay rules yet.

[DeathAndTaxes]

You have a few very small outputs and a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.

How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee.

The fee is 0.0001 per KB on low priority txs.  Your tx is over 1KB so the min fee would be 0.0002 not sure why your client didn't calculate it correctly.