NO confirmations after almost 3 days

[jojo69]

[Automatic]

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

[CoinByCall]

Hello! I'm the guy who sent the transactions. At my service CoinByCall.com a python script is constantly (once per minute or so) checking whether users have reached their configured payout-threshold, and if so, sends a shell command to bitcoind (sendfrom... ) running on a Linux box, telling it to send the payout-amount to the users' configured BTC address. The system has been working like this fine since June 2013. Around the time serje didn't receive his payout I had the system synchronize a lot of user accounts (yet unaccounted calls -> accounted calls) so their balance would be up-to-date as the system was really lagging behind. However, the associated wallet where coins were sent from always had a balance of 2 BTC or more AFAIK. But it's true that I was buying more BTC during this time (a period of 10-15 hours) than usual. Could it be that my bitcoind sent coins from an "amount of coins" that I bought that was still unconfirmed, even though my wallet had enough confirmed coins (always 2+ BTC)? Sorry for the lame terminology, I hope you get what I mean.

I checked the transactions around the time serje's was sent and indeed, there are about 15 or so transactions that even today still have 0 confirmations.

[Automatic]

Hello! I'm the guy who sent the transactions. At my service CoinByCall.com a python script is constantly (once per minute or so) checking whether users have reached their configured payout-threshold, and if so, sends a shell command to bitcoind (sendfrom... ) running on a Linux box, telling it to send the payout-amount to the users' configured BTC address. The system has been working like this fine since June 2013. Around the time serje didn't receive his payout I had the system synchronize a lot of user accounts (yet unaccounted calls -> accounted calls) so their balance would be up-to-date as the system was really lagging behind. However, the associated wallet where coins were sent from always had a balance of 2 BTC or more AFAIK. But it's true that I was buying more BTC during this time (a period of 10-15 hours) than usual. Could it be that my bitcoind sent coins from an "amount of coins" that I bought that was still unconfirmed, even though my wallet had enough confirmed coins (always 2+ BTC)? Sorry for the lame terminology, I hope you get what I mean.

I checked the transactions around the time serje's was sent and indeed, there are about 15 or so transactions that even today still have 0 confirmations.

Yes, it could, transactions rely on other transaction's hashes (TXID), you can mutilate a transaction without invalidating it, and, change it's hash (TXID) before it's in a block (or, even after, but, you'd have to generate a longer chain, so, considered super hard/impossible at that point). It's really not recommended to send any transactions that rely on unconfirmed transactions due to the fact that they'll rely on a transaction that could easily be changed, on top of that, it's basically a "no." to chain transactions to different users using transactions that aren't confirmed, like:-

Address A sends transaction1 to AddressB and customerA
Address B sends transaction2 to AddressC and customerB

Now, if transaction1 is mutilated, then, transaction2 is invalidated. Either batch transactions if you have zero confirmed TXIN (Really? Are you that poor? Get more spread out funds for your system), so, transaction1 sends to lots of customers at the same time (And thus, you don't have to rely on different transactions as often, as, you batch them up), make your system delay transactions until you have TXINs that are confirmed, or, simply have more funds spreadout, next time you're transferring money to your system, instead of putting in 50BTC at once, send it a transaction that gives it 500 0.1 inputs, that way, it can always have an unspent input of > 0 confirmations.

EDIT:- Imagine this:-
Key:-
Black = You
Red = Customer(s)
Green = Invalidated due to upstream issues


You, 1MyAwesomeAddress sends money to customer one (1CustomersAddress) in TXID#1, however, some ass changes your transaction and rebroadcasts it as TXID#2, now, before either one is confirmed, you send TXID#3 to 1SecondCustomersAddress, but, rely on TXID#1. TXID#2 is now confirmed, and, TXID#1 is now orphaned, this means anything downstream from TXID#1 is also orphaned, I.E., TXID#3. Customer one still gets their money, and, you still keep your change in 1MyAwesomeOtherAddress, but, any customers in the chain onward from there are fucked, and, you'll have to spend quite a while to go through your logs to try and work out what you owe who (Not a fun job).

[DannyHamilton]

Hello! I'm the guy who sent the transactions. At my service CoinByCall.com a python script is constantly (once per minute or so) checking whether users have reached their configured payout-threshold, and if so, sends a shell command to bitcoind (sendfrom... ) running on a Linux box, telling it to send the payout-amount to the users' configured BTC address. The system has been working like this fine since June 2013. Around the time serje didn't receive his payout I had the system synchronize a lot of user accounts (yet unaccounted calls -> accounted calls) so their balance would be up-to-date as the system was really lagging behind. However, the associated wallet where coins were sent from always had a balance of 2 BTC or more AFAIK. But it's true that I was buying more BTC during this time (a period of 10-15 hours) than usual. Could it be that my bitcoind sent coins from an "amount of coins" that I bought that was still unconfirmed, even though my wallet had enough confirmed coins (always 2+ BTC)? Sorry for the lame terminology, I hope you get what I mean.

I checked the transactions around the time serje's was sent and indeed, there are about 15 or so transactions that even today still have 0 confirmations.

This is almost certainly due to "Transaction Malleability".  If you are not familiar with this term, and you are running a service that sends automated payments, then you need to take some time to learn about it.  It has significant consequences if you are sending transactions using bitcoins from other transactions that have not yet confirmed.

Most likely, you sent a transaction, and the change from the transaction was sent back into your wallet.  Your service then generated a chain of transactions all spending the change from the previous unconfirmed transaction.  Meanwhile, some prankster on the internet modified your original transaction to have a different transactionID (they cannot modify the actual bitcoins spent or the addresses that receive the bitcoins, but until the transaction is confirmed they can modify the transactionID).  This modified transactionID got confirmed instead of the original transactionID that you sent.  Since each new transaction in the chain of transactions that you sent relies on spending an output from a previous transactionID, they all link back to that first modified transaction.  Since that transactionID wasn't confirmed, (and the modfied version of it was instead), none of these transactions will ever confirm.

You'll need to create a list of recipients and how much you owe each of them.
Then you'll need to remove all these invalid transactions from your wallet.
Then you'll need to re-create new transactions to send bitcoins to the intended recipients (being careful not to spend any unconfirmed inputs).
Then you'll need to take a look at your programming and make sure that it doesn't try to spend unconfirmed outputs in the future.

[CoinByCall]

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

[Automatic]

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	 <fromaccount> {address:amount,...} [minconf=1] [comment]

or

Code:

sendfrom	 <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to]

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

[CoinByCall]

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 ?

[DannyHamilton]

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.

[Automatic]

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

[CoinByCall]

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.

[CoinByCall]

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.

[jojo69]

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.

[spin]

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?

[DannyHamilton]

minconf does not apply to change.

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

[Automatic]

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.

[leemajors]

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]

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]

blockchain

[Automatic]

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.