where are my bitcoins

[stslimited]

I have 5.8 btc stuck in limbo somewhere, I sent with the .0005 transaction fee @ 14:55, it is now 16:23



  8ab383eb0d039dbde4707cf03ca2e982f9c2879f1d35a4b03ea0876053db083e: Seen by 1 peer. Not seen in chain.
     from 1GPqdANK9TXinouQXUMzxLVVPSvobM4zq6 / 8f3da7aa8e78394df8d3384347e97a32dc19de0e33906be6b6de4641f174b880:1
     from 1GPqdANK9TXinouQXUMzxLVVPSvobM4zq6 / 60c51e4e99b0152c32e922a880309945b9092a857078b41133e3976a60907a62:1
       to 1PF59kWu2byBH3BAqBvHjXyDkAvzkyohpH 5.8024 BTC
       to 1GPqdANK9TXinouQXUMzxLVVPSvobM4zq6 0.00000939 BTC

[Remember remember the 5th of November]

If you delete this TX from your wallet, you can re-spend the coins since the network didn't hear your TX either way.

[jim618]

It is most likely your change output is too small - transactions with outputs less than 5430 satoshi don't propagate across the network now.

I suggest you update to version 0.5.12 of MultiBit (the current one on the https://multibit.org site).
Then you will want to do a 'Tools | Reset blockchain and transactions' to sync back to the blockchain. The transaction you posted never made it successfully into the Bitcoin network so will disappear.

Then send the transaction again. The latest version does not generate 'tiny change' outputs - it gets bundled into the fee as a little bonus for the miner.

[stslimited]

It is most likely your change output is too small - transactions with outputs less than 5430 satoshi don't propagate across the network now.

I suggest you update to version 0.5.12 of MultiBit (the current one on the https://multibit.org site).
Then you will want to do a 'Tools | Reset blockchain and transactions' to sync back to the blockchain. The transaction you posted never made it successfully into the Bitcoin network so will disappear.

Then send the transaction again. The latest version does not generate 'tiny change' outputs - it gets bundled into the fee as a little bonus for the miner.

ok did this now

when will it disappear?

[stslimited]

If you delete this TX from your wallet, you can re-spend the coins since the network didn't hear your TX either way.

how do I do that? I've never needed to do this before

[DeathAndTaxes]

It is most likely your change output is too small - transactions with outputs less than 5430 satoshi don't propagate across the network now.

I suggest you update to version 0.5.12 of MultiBit (the current one on the https://multibit.org site).
Then you will want to do a 'Tools | Reset blockchain and transactions' to sync back to the blockchain. The transaction you posted never made it successfully into the Bitcoin network so will disappear.

Then send the transaction again. The latest version does not generate 'tiny change' outputs - it gets bundled into the fee as a little bonus for the miner.

ok did this now

when will it disappear?

Each node if different however since your tx isn't compliant it is very likely that every peer dropped it the second you transmitted it.  You can try spending again at any time.  Each peer/node will relay it unless they already have received the older version of the transaction.

A hint if that seems confusing.  There is no such thing as "the network" Bitcoin is a network of independent peer nodes.  So nobody can know what all peer nodes will do unless they have access to all the peer nodes.  However it really isn't important.  If at least one of your direct peers rejected the old transaction it will accept and relay the new one.

[redtwitz]

The transaction has been confirmed now. Thank Eclipse for ignoring the devs' new policy.

[stslimited]

The transaction has been confirmed now. Thank Eclipse for ignoring the devs' new policy.

okay I am still conceptualizing what just happened



I see that it is being confirmed now, how did that happen? I thought it would be sent back to me first after I "deleted the TX from my wallet" or waited long enough

I upgraded multibit, given that this is being confirmed now, was upgrading the client a factor in it being confirmed

who is eclipse, the java IDE?

[cp1]

Eclipse is a mining pool.

[DeathAndTaxes]

The transaction has been confirmed now. Thank Eclipse for ignoring the devs' new policy.

okay I am still conceptualizing what just happened



I see that it is being confirmed now, how did that happen? I thought it would be sent back to me first after I "deleted the TX from my wallet" or waited long enough

I upgraded multibit, given that this is being confirmed now, was upgrading the client a factor in it being confirmed

who is eclipse, the java IDE?

You can't affect other nodes.  You deleted your local copy of the tx and eventually other nodes would have deleted it as well (because your node would stop broadcasting it) however you deleting your local copy doesn't force other nodes to do the same.  They actually have no idea you deleted your local copy.  A copy of the tx was still on one or more nodes and one or more of those nodes relayed it to a miner who mines tx below the dust threshold.  That miner found a block and your tx was included.

Remember try not to think about Bitcoin as some "network" (which creates an impression of a single unified system).  Bitcoin consists of nodes which happen to follow similar rules.  All you can do is control your node.  You have absolutely no control over any other node on the network.  All nodes work independently.

[redtwitz]

The network doesn't care if you deleted the transaction from your wallet. Once it has been broadcast, it's up to the miners if they include in in their blocks or not. You cannot undo a transaction. You can only delete it from your client and try again. As long as your client uses the same unspent outputs for both transactions, the first transaction will be discarded if your second transaction gets included in a block before the first one, since you cannot spend the same output twice.

Eclipse Mining Consortium is - according to blockchain.info - the mining pool that chose to include your transaction in a block.

[jim618]

This thread is a great example.of some of the subtleties of Bitcoin.

Also to throw into the mix is that when the OP updated his software he no doubt started it up again. MultiBit automatically retransmits transactions that did not propagate out previously.  It connects to random bitcoind nodes when it starts up. This time it started the node it passed the transaction to may have decided to pass it on.

[stslimited]

This thread is a great example.of some of the subtleties of Bitcoin.

Also to throw into the mix is that when the OP updated his software he no doubt started it up again. MultiBit automatically retransmits transactions that did not propagate out previously.  It connects to random bitcoind nodes when it starts up. This time it started the node it passed the transaction to may have decided to pass it on.

thanks for the info, you and everyone

so although this was educational, if I was using the latest multibit I would never have been exposed to this dilemma?

[DeathAndTaxes]

This thread is a great example.of some of the subtleties of Bitcoin.

Also to throw into the mix is that when the OP updated his software he no doubt started it up again. MultiBit automatically retransmits transactions that did not propagate out previously.  It connects to random bitcoind nodes when it starts up. This time it started the node it passed the transaction to may have decided to pass it on.

thanks for the info, you and everyone

so although this was educational, if I was using the latest multibit I would never have been exposed to this dilemma?

Correct.  It comes from the fact that today nodes running 0.8.2 or higher will (by default) reject tx which have outputs less than 5,430 S, that is 54.3% of the min mandatory fee (10,000 S).  If the entire network was running 0.8.2+ with default rules your tx would not have gone anywhere, if you were running latest version of client it would have prevented you from making this transaction.   As it stands right now some node are running older versions of the client and thus your tx "got through".  In time as the % of nodes running 0.8.2 (or equivalent for non-reference clients) increases the chance that a similar transaction will be able to find a compatible node to relay it will be greatly reduced.

[gen. specific]

reserved