Bitcoin Forum

Hello,

I am new to Bitcoin; I tried to make a transaction from Bitcoin faucet.

After about two hours, the transaction appeared with a 0/unconfirmed status.

This morning (about two hours ago) I started my computer and the transaction still had this unconfirmed status.

Here is the address I used for this transaction:

1HmxsQBuWZMUGaZSA65KQZBRkh6FvXvmjA

In the status bar I can see: 8 connections / 111196 blocks / 1 transactions.

What could be wrong?

Thanks!

If it can help, I'm using the 3.20.1-beta version for Mac OS X.

Hm, not sure why that is happening.
maybe it helps starting bitcoin with the -rescan switch

According to the block explorer your address has never been used.

It's weird, if you see the 0/unconfirmed transaction it means the transaction was signed by the faucet and you received it on your client... why hasn't it been added to any block, I don't know... I mean, it seems the network forgot about it. I thought that in such situations your client (or that of the faucet) would rebroadcast it.

Unless there's something quite unusual with your transaction that is making every miner to refuse it. But why would the faucet produce a non-standard transaction and how come your client recognized it?

Won't help, it seems the transaction hasn't yet been added to the block chain.

Well, but how did I receive it then?

I'm posting some screenshots here.

http://i.pirine.fr/2011/bc-main.png

http://i.pirine.fr/2011/bc-details.png

http://freebitcoins.appspot.com/ told me this morning it already gave me 0.05 coins but now it allows me to send bitcoins again. So I just did it again. This time, it appeared within seconds:

http://i.pirine.fr/2011/bc-main2.png

Some news:

I've just created another address and sent a payement through my server (using SOCKS proxy, so I can have a different IP).

It seems to work this time:

http://i.pirine.fr/2011/bc-main3.png

So the problem is with my first address? What's wrong with it?

This is weird, I fail to understand what is the issue.

Does anyone else know if there's a way to dump the transaction pool?

The only thing that makes sense to me is that the transactions which have your address as output are not standard, but if it's the case, then it's probably a bug in the software, since I believe the faucet uses bitcoind to send its transactions.

It would be nice if somebody with a better knowledge of the source could take a look at this. Bump this thread tomorrow if you don't get any answer. The forums have been so busy lately, people might not notice your thread.

This is a little bit worrying, since several people reported this...

Really? It's the first one I see.
Do you know if there's a way to dump the transaction pool, so people could see if there's anything particular with his transaction?

not the first one i see.
just noticed one transaction today that also needed ~3hours to get its first confirmation, while other transactions done at the same time got confirmed as usual within a few minutes.
some other people been waiting 12hours and more, to get 1conf.

so i doubt it's something with his transaction.

Today, I've sent a test 1 BTC transaction with about 4KB size (which will be low priority) and it's not included in any block after a few hours so it's not an isolated case.

A vary bad feature of the client is that it is not giving a warning about a very low priority payment. And of course there is no standard way to resend a transaction with a fee included if it is not confirmed after xx blocks.

This seems to be the cause of all the recent problems. The transactions will confirm eventually, but it will take at least several days.

The maximum block size is 10KB isn't it? So this isn't a problem of priority. There's enough space to include all of them. Plus, I've just checked a few of the last blocks, and them all contained free transactions, what means that miners are not deliberately refusing free transactions either.

There must be something particular to these transactions that don't get added...

The maximum block size is 500 kB (1MB receiving), but if the block size is over 4kB, low-priority free transactions will not be accepted. It's possible to create a transaction over 4kB that always triggers this and never gets in a block until its priority rises with age.

Okay, the default client transaction policy. So, most custom miners are just following it... I thought people would create their own policies...

Anyway, so there's nothing digimag can do but wait.

Well, bank transfers can take up to 10 days with PayPal, so a few days may not be so bad I guess…

Besides, the faucet gives you free money... you can't complain about the delay. ;)

But this is interesting anyway. A few free transactions are starting to have a hard time getting included in the block chain... if this fee policy keeps being used by most miners, maybe it won't take much longer for it to become difficult to send any free transaction. People in a hurry will have to start adding fees.

Payement received :)

It took 24 hours.

It might be bad timing for Bitcoin but it's still quite good compared to real bank transfers!

There are at this time over 2,000 unconfirmed transactions queued, some more than 24 hours old.
 http://bitcoincharts.com/bitcoin


Is this the end of the road for having a free ewallet provider (e.g., MyBitcoin) due to the end of the "free transactions" era?

Thread necromancy.
Pretty much all of those are really low-scoring penny spam, legit free transactions should still get into blocks quick enough thanks to dPriority.

Why are low BTC transactions considered illegitimate or spam?

If someone wanted to attack the network, they could send a large number of very small transactions since the cost to do so is small.  There is code in the client to guard against this.

Are you referring to the "limitfreerelay", which is planned to be in the next release (Bitcoin v0.3.21)?
  http://bitcointalk.org/index.php?topic=4009.0 (http://bitcointalk.org/index.php?topic=4009.0)

The priority system is already in effect, which is preventing those spam transactions from getting into blocks.

i looked at it this morning and it was down to less than 100 unconfirmed.  at current time, it's exactly 1000.

the wild swing in the length of the unconfirmed queue is probably due to the periodic behavior of the network speed.  Lots of people are hashing at night when they're not using their systems (Like I am), and there isn't enough of a time zone distribution (the vast majority of people running bitcoin are in North America and western Europe.  There's practically nothing in Asia or Australia) to make up for that, so all the overnight hashers clear the day's backlog (mostly) and then stop hashing during the day, causing a backlog to build up, which is then cleared overnight.

as this chart shows, the network speed swings wildly depending on time of day.

http://bitcoin.sipa.be/speed-lin-2k.png

Just putting in my two cents that I too have two 0/unconfirmed transactions supposed to go to the donation address of bitcoin-otc. Was send about 6.5 hrs ago. Still 0/unconfirmed.

low amount = low priority.

There would be nice if there was some info in the client that the transaction actually was broadcast to the network, and it's status. I might file a feature request on this one. At the moment I have 3 transactions that are "0/unconfirmed".

As long as it's noted as "0/unconfirmed" and I have successfully both received and sent BTC during this time, I find it a bit odd.

But I'll just wait some more and see.

Also I have been using different client versions (whithout meaning to) on my wallet recently. I suspect there might be a bug that causes this issue. I got some warning about possible double spending, and I don't know if this will prevent the client from retrying sending the transactions out to the network. There's been no double spending, just running 0.3.21-beta and 0.3.20.01 both on the same data directory AppData/Roaming/Bitcoin.

I tought that including a fee would speed up transfer of a transaction?

As it is now I have two transfers with 0.1 fee waiting, and one with no fee (perhaps I sent that with the older client?)

So this is the status now:
http://imageshack.us/photo/my-images/703/mining2.png/

Frankly I am concerned there might be incompabilities between different bitcoin client versions that will cause problems, since I've had two different clients working on my data-directory as stated above.

The transfer of 4.81 BTC includes a fee of 0.1 and is newly made coins, I understand these takes longer to process in the network?

So what I am really worried about is that there might be some protocol or client issue. This is not a lot of money, but it would not have been fun to have this happen to a larger amount of BTC. But according to what the topic starter wrote, perhaps I should just wait more. Then we will see, I will keep you updated.

I have 0/unconfirmed on a transaction that got in a block 43 blocks ago. Is that something I should worry about?

edit: seems like there are no inputs, although there are shown on blockexplorer (http://blockexplorer.com/t/9CT9DaNSjC)
-----

debug print
Credit: 0.14
Transaction:
CTransaction(hash=d85106b467, ver=1, vin.size=1, vout.size=2, nLockTime=0)
   CTxIn(COutPoint(d4aa1257fd, 1), scriptSig=3046022100e3f82c1755e927)
   CTxOut(nValue=1.86000000, scriptPubKey=OP_DUP OP_HASH160 c8c029ce1ace)
   CTxOut(nValue=0.14000000, scriptPubKey=OP_DUP OP_HASH160 198d80f19e84)
Inputs:

edit2: redownloaded the block chain and it's ok now. Weird, as I tried -rescan also.