0/unconfirmed status for about 12 hours

[ArtForz]

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.

[1715165788]

1715165788

[Qoad Sof]

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?

[Cryptoman]

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.

[Stephen Gornick]

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

[theymos]

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

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

[compro01]

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

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.

[Herodes]

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.

[grue]

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.

[Herodes]

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.

[vuce]

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

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.