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.
Topic: 0/unconfirmed status for about 12 hours (Read 6016 times)
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.
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.
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.
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.
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.
Are you referring to the "limitfreerelay", which is planned to be in the next release (Bitcoin v0.3.21)?
https://bitcointalksearch.org/topic/createtransaction-suggestenforce-fee-for-big-low-priority-transactions-4009
https://bitcointalksearch.org/topic/createtransaction-suggestenforce-fee-for-big-low-priority-transactions-4009
The priority system is already in effect, which is preventing those spam transactions from getting into blocks.
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)?
https://bitcointalksearch.org/topic/createtransaction-suggestenforce-fee-for-big-low-priority-transactions-4009
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.
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.
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.
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?
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.
Pretty much all of those are really low-scoring penny spam, legit free transactions should still get into blocks quick enough thanks to dPriority.
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?
Payement received 
It took 24 hours.
It might be bad timing for Bitcoin but it's still quite good compared to real bank transfers!
It took 24 hours.
It might be bad timing for Bitcoin but it's still quite good compared to real bank transfers!
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.
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.
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…
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.
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...
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.
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...
There must be something particular to these transactions that don't get added...
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.
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.
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.
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.
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.
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.
Jump to: