NO confirmations after almost 3 days

serje

legendary

Activity: 1232

Merit: 1002

Quote from: CoinByCall on March 09, 2014, 07:19:19 PM

Thanks. It's a heavily overloaded VPS, load average 50-80. Took 20 hours or so. I recreated all 0-confirmations transactions manually and this time it worked. They all got 3+ confirms by now.

I'm starting to think there is some bug somewhere related to high server load. Maybe in combination with a situation where there are several TX'es sent in a row. I upgraded from 0.8.2 to 0.8.6 just in case.

I confirm I received my BTC !

Thanks to everyone involved!

CoinByCall

sr. member

Activity: 457

Merit: 250

Thanks. It's a heavily overloaded VPS, load average 50-80. Took 20 hours or so. I recreated all 0-confirmations transactions manually and this time it worked. They all got 3+ confirms by now.

I'm starting to think there is some bug somewhere related to high server load. Maybe in combination with a situation where there are several TX'es sent in a row. I upgraded from 0.8.2 to 0.8.6 just in case.

Automatic

full member

Activity: 238

Merit: 109

Quote from: CoinByCall on March 09, 2014, 01:27:51 AM

Quote from: donsanto on March 08, 2014, 10:45:13 PM

Has anyone suggested a simple -rescan to see if the coins show up. I had an issue with a 0 confirmation transaction did rescan and they showed up again.

Actually this is what I'm doing right now. But first I deleted all the transactions using PyWallet and I'm going to create the ones with 0 confirmations afterwards again manually.

May I ask how long -rescan took for you? Here it's been at it for about 10 hours now. Normal?

On my 3.33GHz hex core CPU, with an SSD to read the blocks off of, it takes about an hour. On my virtual machine that I was testing a program out before releasing it, it took over 24 hours. On my production VPS I leased (Single core @ ~ 2.5GHz, 512MB ram) it took over three days.

Really depends on the specs, but, if you have a some-what decent computer, it really shouldn't take ten hours.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: CoinByCall on March 09, 2014, 01:27:51 AM

Quote from: donsanto on March 08, 2014, 10:45:13 PM

Has anyone suggested a simple -rescan to see if the coins show up. I had an issue with a 0 confirmation transaction did rescan and they showed up again.

Actually this is what I'm doing right now. But first I deleted all the transactions using PyWallet and I'm going to create the ones with 0 confirmations afterwards again manually.

May I ask how long -rescan took for you? Here it's been at it for about 10 hours now. Normal?

No, it takes me about an hour or two to rescan, on an i7.

.. and yeah, you just have to export the private key then import it.... then rescan.

CoinByCall

sr. member

Activity: 457

Merit: 250

Quote from: donsanto on March 08, 2014, 10:45:13 PM

Has anyone suggested a simple -rescan to see if the coins show up. I had an issue with a 0 confirmation transaction did rescan and they showed up again.

Actually this is what I'm doing right now. But first I deleted all the transactions using PyWallet and I'm going to create the ones with 0 confirmations afterwards again manually.

May I ask how long -rescan took for you? Here it's been at it for about 10 hours now. Normal?

donsanto

newbie

Activity: 22

Merit: 0

Has anyone suggested a simple -rescan to see if the coins show up. I had an issue with a 0 confirmation transaction did rescan and they showed up again.

Automatic

full member

Activity: 238

Merit: 109

Quote from: leemajors on March 05, 2014, 11:09:34 AM

blockchain

Unfortunately, I don't believe this data is available to the end-user on blockchain.info, I may be wrong, I don't use them for anything but a simple way to check balances/etc...

I'd wait for someone else who actually uses their wallet service to reply, however.

leemajors

newbie

Activity: 3

Merit: 0

blockchain

Automatic

full member

Activity: 238

Merit: 109

Quote from: leemajors on March 05, 2014, 10:36:42 AM

I too am having the same problem no conformation been 2 days now i have read this thread and got some help but i need to find out where do i get the raw data so i can rebroadcast it in https://blockchain.info/pushtx

What client are you using?

leemajors

newbie

Activity: 3

Merit: 0

I too am having the same problem no conformation been 2 days now i have read this thread and got some help but i need to find out where do i get the raw data so i can rebroadcast it in https://blockchain.info/pushtx

Automatic

full member

Activity: 238

Merit: 109

Quote from: spin on March 05, 2014, 06:45:01 AM

Quote from: DannyHamilton on March 04, 2014, 01:12:17 PM

Quote from: CoinByCall on March 04, 2014, 01:07:52 PM

I'm using "sendfrom" and I'm not changing "minconf". If the default is 1, then why did my bitcoind send transactions based on unconfirmed incoming TX? Ah, maybe because 1 confirmation is not enough to not get messed with and I should set it to minconf=3 ?

It is quite rare for a transaction with 1 confirmation to become victim to transaction malleability.

You would need the competing transaction to end up in a competing block which eventually orphans the block where you see the 1 conf.

Perhaps there is a bug in bitcoind and minconf is not defaulting to 1? Perhaps some testing is needed on this matter, to confirm what you're saying.

I thought minconf only applies to unconfirmed transactions from external parties. minconf does not apply to change.
So some of your change may have been uncormfirmed when you sent a batch of transactions. Some of those may have been mutated which resulted in some of subsequent transactions not going through.

They are adding an option for unconfirmed change going forward. Might be in 0.9rc2? See: https://github.com/bitcoin/bitcoin/pull/3651

A possibly workaround now would be to batch multiple payouts in one transaction. Rather than chaining them one after the other. Should save some fees also?

If that's the case, just use createrawtransaction & listunspent. Not the best, but, oh well.

DannyHamilton

legendary

Activity: 3472

Merit: 4801

Quote from: spin on March 05, 2014, 06:45:01 AM

minconf does not apply to change.

That would make sense, I suspect you're right. Hopefully this will be addressed in a future version.

spin

sr. member

Activity: 362

Merit: 262

Quote from: DannyHamilton on March 04, 2014, 01:12:17 PM

Quote from: CoinByCall on March 04, 2014, 01:07:52 PM

I'm using "sendfrom" and I'm not changing "minconf". If the default is 1, then why did my bitcoind send transactions based on unconfirmed incoming TX? Ah, maybe because 1 confirmation is not enough to not get messed with and I should set it to minconf=3 ?

It is quite rare for a transaction with 1 confirmation to become victim to transaction malleability.

You would need the competing transaction to end up in a competing block which eventually orphans the block where you see the 1 conf.

Perhaps there is a bug in bitcoind and minconf is not defaulting to 1? Perhaps some testing is needed on this matter, to confirm what you're saying.

I thought minconf only applies to unconfirmed transactions from external parties. minconf does not apply to change.
So some of your change may have been uncormfirmed when you sent a batch of transactions. Some of those may have been mutated which resulted in some of subsequent transactions not going through.

They are adding an option for unconfirmed change going forward. Might be in 0.9rc2? See: https://github.com/bitcoin/bitcoin/pull/3651

A possibly workaround now would be to batch multiple payouts in one transaction. Rather than chaining them one after the other. Should save some fees also?

jojo69

legendary

Activity: 3374

Merit: 4738

diamond-handed zealot

Quote from: Automatic on March 04, 2014, 11:32:56 AM

How is this useful at-all? It's not even an entertaining thread, just someone who can't follow a chain.

Well excuse me, I did find the thread entertaining. And if you found the gif so objectionable there was no need to quote it.

CoinByCall

sr. member

Activity: 457

Merit: 250

And it's not like all TX'es on the 2014-02-26 event have 0 confirmations. It goes like this:

2014-02-26 00:54:50: 0 confirmations
2014-02-26 00:54:52: 1093 confirmations
2014-02-26 00:54:52: 0 confirmations
2014-02-26 00:55:00: 1093 confirmations
2014-02-26 00:55:19: 0 confirmations
2014-02-26 00:55:20: 1093 confirmations
2014-02-26 00:55:29: 1093 confirmations
2014-02-26 00:55:31: 1093 confirmations
2014-02-26 00:55:39: 1093 confirmations
2014-02-26 00:55:47: 1093 confirmations
2014-02-26 00:55:55: 0 confirmations
2014-02-26 00:55:55: 1093 confirmations
...and so on.

CoinByCall

sr. member

Activity: 457

Merit: 250

Quote from: Automatic on March 04, 2014, 01:23:22 PM

I'm unsure why it failed, can I ask, have you messed around with the account features? I notice it's uses accounts, and, accounts are the most accurate things (I can have an account with infinite BTC, if I want).

Nope, I haven't messed with anything. I just checked all transactions in 2014 and I have 20 outgoing TX with 0 confirmations from a total of 1063 transactions:

1. 2014-02-10 20:33:14
2. 2014-02-11 04:02:15
3. 2014-02-11 05:02:29
4. 2014-02-26 00:54:50
5. 2014-02-26 00:54:52
6. 2014-02-26 00:55:19
7. 2014-02-26 00:55:55
8. 2014-02-26 00:56:09
9. 2014-02-26 00:56:09
10. 2014-02-26 00:56:11
11. 2014-02-26 00:56:11
12. 2014-02-26 00:56:12
13. 2014-02-26 00:56:13
14. 2014-02-26 00:56:20
15. 2014-02-26 00:56:21
16. 2014-02-26 00:56:22
17. 2014-02-26 00:56:22
18. 2014-02-26 00:56:23
19. 2014-02-26 00:56:31
20. 2014-02-26 01:04:11

Each TX is in the range of 0.01 to 0.03 BTC and all have a fee of 0.0001 BTC.

serje's TX is part of the 2014-02-26 event. This was when I synchronized all users' balances because the system was/still is heavily overloaded and balances were not up-to-date. Afterwards, the payment script was run and many TX were sent in a row. This is not the usual behavior. Usually 1 TX is sent every 30 minutes or so. That's the only difference I can see (many TX sent in a row) to normal operation. No idea what happened on 10th and 11th February.

Automatic

full member

Activity: 238

Merit: 109

Quote from: DannyHamilton on March 04, 2014, 01:12:17 PM

Quote from: CoinByCall on March 04, 2014, 01:07:52 PM

I'm using "sendfrom" and I'm not changing "minconf". If the default is 1, then why did my bitcoind send transactions based on unconfirmed incoming TX? Ah, maybe because 1 confirmation is not enough to not get messed with and I should set it to minconf=3 ?

It is quite rare for a transaction with 1 confirmation to become victim to transaction malleability.

You would need the competing transaction to end up in a competing block which eventually orphans the block where you see the 1 conf.

Perhaps there is a bug in bitcoind and minconf is not defaulting to 1? Perhaps some testing is needed on this matter, to confirm what you're saying.

I looked into the source, it does default to 1, it's quite clear:-
https://github.com/bitcoin/bitcoin/blob/f60e49d49c72908356d70d05ae30c6e63be2192d/src/rpcwallet.cpp#L765-L767

Simple as:

Code:

value = 1;
if(customValue) value = customValue;

Anyway, sendfrom only verifies that you have enough funds in your wallet that's confirmed at one, it doesn't actually process them there (And uses the normal priority processing).

I'm unsure why it failed, can I ask, have you messed around with the account features? I notice it's uses accounts, and, accounts are the most accurate things (I can have an account with infinite BTC, if I want).

DannyHamilton

legendary

Activity: 3472

Merit: 4801

Quote from: CoinByCall on March 04, 2014, 01:07:52 PM

I'm using "sendfrom" and I'm not changing "minconf". If the default is 1, then why did my bitcoind send transactions based on unconfirmed incoming TX? Ah, maybe because 1 confirmation is not enough to not get messed with and I should set it to minconf=3 ?

It is quite rare for a transaction with 1 confirmation to become victim to transaction malleability.

You would need the competing transaction to end up in a competing block which eventually orphans the block where you see the 1 conf.

Perhaps there is a bug in bitcoind and minconf is not defaulting to 1? Perhaps some testing is needed on this matter, to confirm what you're saying.

CoinByCall

sr. member

Activity: 457

Merit: 250

I'm using "sendfrom" and I'm not changing "minconf". If the default is 1, then why did my bitcoind send transactions based on unconfirmed incoming TX? Ah, maybe because 1 confirmation is not enough to not get messed with and I should set it to minconf=3 ?

Automatic

full member

Activity: 238

Merit: 109

Quote from: CoinByCall on March 04, 2014, 12:59:41 PM

Thanks, I think I got it.

Wouldn't it be helpful if bitcoind had a switch like "do not send transaction if unconfirmed incoming TX exist"?

They do, all over the program:-
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

ctrl+f "conf":-

I think the one you're talking about is:-

Code:

sendmany {address:amount,...} [minconf=1] [comment]

or

Code:

sendfrom [minconf=1] [comment] [comment-to]

Both default to 1. Someone really should read up on the API.

Topic: NO confirmations after almost 3 days (Read 3626 times)