Topic: slow transaction (Read 678 times)

Nope, that's not what happened at all.

The problem is the transactions were being made with funds that hadn't confirmed.  That is essentially all it is.  If that's a problem for you, contact the sender and insist that all future payments be sent only using confirmed funds.

Interesting, thanks for explanation.

I guess the fund is from some mined coin, it's so fresh that the rest of network hardly knows about it.

Yup.  That's no surprise.  Here's the transaction that you say you aren't seeing:
 - http://blockchain.info/tx/72a9ec4eab8349937c326310267261553b0db1cfd6dd1e7d9b8f5668e2e881c2

In order for your node to know about a transaction the peers your node is connected to need to know about it.    So your peers must first see the transaction then they must verify the inputs, and only then will they relay it.

Now here's the problem.

That transaction uses inputs from two other transactions ... two "parents".  Neither parent transaction has confirmed.  Here's one:
 - http://blockchain.info/tx/2b7c5c019a3dbbe8c62cee9900248d010b6abaadd10401b130d1732433c3f1a2

And that transaction, ... 2b7c5c019a3dbbe8c62cee9900248d010b6abaadd10401b130d1732433c3f1a2, itself has a parent, and that parent hasn't confirmed either.  Here's that:
 - http://blockchain.info/tx/550f81600de37788b1010ea8a1cbadab24c7d2c25147df6b5765c0e31d5a3551

And same thing with even 550f81600de37788b1010ea8a1cbadab24c7d2c25147df6b5765c0e31d5a3551's parent:
 - http://blockchain.info/tx/06585f02e5992bd7fdf28f69b1d3f6f91a5a6969c79061ec67c29c17c7f5a1f5

Shall we keep going?  We must ... so that 06585f02e5992bd7fdf28f69b1d3f6f91a5a6969c79061ec67c29c17c7f5a1f5's parent:
 - http://blockchain.info/tx/cb52fd82a3916f3004f7d329250d462b74ed34e67371121ce0bb1b68d0cf188a

Which brings us to cb52fd82a3916f3004f7d329250d462b74ed34e67371121ce0bb1b68d0cf188a's parent ... still not confirmed:
 - http://blockchain.info/tx/f44a37fa096958d0b41f0109b152a626384832f9011b6e3baf77fbd096b462a9

And finally f44a37fa096958d0b41f0109b152a626384832f9011b6e3baf77fbd096b462a9's parent does actually have confirmations:
 - http://blockchain.info/tx/921e5b5dda9d2b3a0f9844442af180590a3b8576985205be6117ab24b072d602

So what is likely happening is the nodes are refusing to relay this transaction (plausible) or more likely the peer node's memory pool is only so big and not all these spam-like transactions are saved long enough and thus your transaction is invalid (the parent transactions can't be found when searching the memory pool).

The solution is to stop doing this crap.  (i.e.,As a commercial provider, don't send out a payment unless the funds you are using for the payment themselves have many, many confirmations.  Your customers deserve better than that.)

Bitcoin is not good for microtransactions.    I know that revelation ruins the business plans of all these "free bitcoin" sites but them's the breaks.  Nobody is going to tell them that no, they can't do this.  But the Bitcoin-Qt/bitcoind client was designed to be resilient against attack and this looks more like an attack than legitimate value transfers.

What the mining pools (or freebie coin service, or whatever it is) can do is maintain a wallet for each user and then when some payout threshold is reached (e.g., a nickel's worth of bitcoins) then and only then is the payout sent through the blockchain.

Now the resolution for this is, ... if the node which first broadcast the "top" spend transaction (f44a37fa096958d0b41f0109b152a626384832f9011b6e3baf77fbd096b462a9) then continuously re-broadcasts that (which is the default, at least once an hour if it has not seen a confirmation), then eventually a miner will take that transaction and it confirms.  It may take a day or so.   Then the next transaction in the sequence (cb52fd82a3916f3004f7d329250d462b74ed34e67371121ce0bb1b68d0cf188a) would get re-broadcast and mined ... that's another day or so.  Then repeat for each in the sequence.  So it is possible your client won't see that transaction for nearly a whole week.      

not to worry, I'm sure that it will confirm soon

I tried --rescan, it did not help.

Well, the 28 satoshis is the dividend test from the ASICMINER's friedcat,
then he just sent another 5.3btc (http://blockchain.info/address/1HMzzDYhKhjhYxnAGcVKNj3ZwvfyvajDia) for the real dividend, which I also don't see on my client, both transactions are still unconfirm.

Seems like my client don't see any transactions from friedcat.

EDIT:
This is the second report of a problem like this using 0.8 that I've seen reported today.  I'm beginning to wonder if there's a bug in 0.8qt.

See Stephen Gornick's explanation below.  He took the time to look into this further than I did.  You will need to complain to the person who sent you the transaction and ask them to stop sending transactions that use unconfirmed inputs.  This is their fault.  If they refuse, you can opt to take your business elsewhere.

Try a rescan.

Shut down the client.  Once it has shut all the way down, start it up from a command line with the --rescan option and wait for the client to scan the entire blockchain (don't worry, it won't be re-downloading the whole thing, it'll just scan it for missed transactions).  It should take less than a couple of hours to complete.  If that doesn't help you can keep an eye on this disccuion and see if they find a cause/solution that you can try:

0.8qt. yes.

I curious why it doesn't show up, so I sent another transaction, and it shows right away.

Odd.  Are you using the Bitcoin-Qt client? If so, has your client caught up with synchronization?

Every time I send coins from one wallet to another, the amount shows up right away on destination client even it has 0 confirmation.

Until,

http://blockchain.info/address/1HMzzDYhKhjhYxnAGcVKNj3ZwvfyvajDia

the 28 satoshi, although, shows up on blockchain web, my client still don't see it.

I guess i will see it when it has at least 1 confirmation.

Can somebody explain how does this happen?