Bitcoin Forum

this was sent wit bitcoin daemon

can anyone help me?

{
    "amount" : -0.02262079,
    "fee" : -0.00010000,
    "confirmations" : 0,
    "txid" : "0d32dec3feea7f48d2b7b7ae99686e48403ea9f7f135688c9d2547aa75998fb0",
    "time" : 1393373049,
    "timereceived" : 1393373049,
    "details" : [
        {
            "account" : "",
            "address" : "1MorjW7nxrnACk29QtomrrQSD3kXnWaddT",
            "category" : "send",
            "amount" : -0.02262079,
            "fee" : -0.00010000
        }
    ]
}

What's the raw transaction? Run this:


Then try broadcasting it from here: https://coinb.in/send-raw-transaction.html

At the moment coinb.in has some technical difficulties

  We're currently experiecing some techincal issues. Service will return to normal shortly. Sorry for any inconvenience caused.

but i will let you know if it worked!

Thank you!

Try rebroadcasting here http://blockchain.info/pushtx

What this means ?
Unable To find all tx inputs: [17392d74a8dcf0ddec3183664bc6c564ca69224c4eb0b07cd774dccc6b015b92]

Means a transaction you're relying on doesn't exist in their DB, can you run:-


Please?

It sounds like your wallet attempted to spend an unconfirmed transaction.  Due to transaction malleability the transactionID of the unconfirmed transaction changed when it was confirmed.  This means that the transaction that was attempting to spend that previously unconfirmed transaction is now referencing the wrong transactionID.

Another possibility would be if a transaction that was sent to you was never confirmed, and the person sending it sent those same bitcoins elsewhere.  Again, it can only create this problem you are seeing if you attempted to spend the unconfirmed bitcoins.  In that case your wallet no longer has access to the bitcoins it is trying to spend.

Either way, you'll most likely need to remove transactionID 0d32dec3feea7f48d2b7b7ae99686e48403ea9f7f135688c9d2547aa75998fb0 from the wallet (since it is most likely no longer a valid transaction).  And will need to re-send the 0.02262079 BTC to 1MorjW7nxrnACk29QtomrrQSD3kXnWaddT.

As has been indicated, the transaction you are asking about is attempting to spend bitcoins that it received with transactionID 17392d74a8dcf0ddec3183664bc6c564ca69224c4eb0b07cd774dccc6b015b92.  This transactionID does not exist in the blockchain, so we are unable to determine what is wrong with it.  If you run getrawtransaction as requested, and post the results here, we may be able to determine why that transaction is not in the blockchain and how your wallet got into the state it is in.

Your transaction must have been declined after so long u should check your address on blockchain.info to see if its been refunded then follow advice above this post and try again or use a safe wallet like electrum, also its best to use new addresses after using one a few times

Thank you all for your help!
I'm really greatful!
I'm the receiver in this transaction this is why everthing goes so slow
You tell me what to do i send an email and hope the other guy will read it! :)

Check to see if it's already been spent (On a site like blockchain/blockexplorer), if it has, confirm it's not a mutated version of the same transaction, if it isn't, and, it's spent, contact the guy who sent you the money and complain he double spent your money. If it's not spent, just broadcast the transaction again (sendrawtransaction, https://blockchain.info/pushtx, https://coinb.in/send-raw-transaction.html, http://eligius.st/~wizkid057/newstats/pushtxn.php)

Or, if the transaction isn't private, just post the output of these two commands:-

And I'm sure someone will be able to give you more info.

How do I know if a transaction is private?

I mean if it's something you don't publicly want to share with the world that's bound to your username (Although, at this point, it's pretty much already is once it's confirmed as you've posted the hash).

Like, personally, there's a few transactions I do that I wouldn't want bound to my name, for one reason or another.

I only have this one at the moment!
getrawtransaction 0d32dec3feea7f48d2b7b7ae99686e48403ea9f7f135688c9d2547aa75998fb0

The raw transaction is:

0100000001925b016bccdc74d77cb0b04e4c2269ca64c5c64b668331ecddf0dca8742d391700000 0006a473044022038b2e9177ae83b9f1192970401d2d7089b0b3ae2c19d2718c3fed6ebc7326f9f 022027cd9d5510b9d7688cb0545f35ff0bfac3a1ee4396fd5ec5993918ca76af39c60121028b5a9 dae7b2e5bc5c2d11e5fa1eaec6db0b4e620d9b374cb2c43f3016260f2c7ffffffff023f84220000 0000001976a914e43f2a2deadcd23c5140cce764073da3fd4d0ee488ac6d739d00000000001976a 9145b581aabf4df54242048777a910b58065301f76288ac00000000


When I get the other rawtransaction will let you know!

If I'm honest, the other one is more important than this one. This one basically is just telling us that you're transferring 0.02262079 to 1MorjW7nxrnACk29QtomrrQSD3kXnWaddT and 0.10318701 to 19Kz33UpsnQhBKAWQukQFwvxKFZh7XSnqi, but, it's relying on txid 17392d74a8dcf0ddec3183664bc6c564ca69224c4eb0b07cd774dccc6b015b92, without that, we have very little information about what's going on.

As soon as I have it I'll post it here!

He sent me this! Also if your re alised who the sender is please don't disclose it!

getrawtransaction 17392d74a8dcf0ddec3183664bc6c564ca69224c4eb0b07cd774dccc6b015b92

0100000001a0df8cbe453e17dc018d66cfac33ad1606e79c771f3b5619ea2c20bf33f6bb0901000 0006c49304602210096c58f2ceb661d160ca7ef17e69b198a5c2f0c022e54fd44cc1e504debee85 41022100da10a5e6f01f4001fe02f226cfd63817928b5d33442b395ae72b285286e1a1f8012103f ae1a639a11abb9ccf989dd01cd090332119f0937ea60b50570c1ccaaac07f6dffffffff02bc1ec0 00000000001976a91497a37b4b389a4852e6db8d00b0201186714d6c4788aca7081700000000001 976a9148e9c7413fc9dd19282b350508dea2ff3330f975888ac00000000

Now do:-

Thanks, this transaction seems to be a huge chain of non-broadcasted transactions, I have a feeling we'll get to the end and see some transaction having been double spent.

Submitting this transaction to:
https://blockchain.info/decode-tx

We see the following:

You can see here that transactionID 17392d...015b92 is spending output #1 from transactionID 09bbf6...8cdfa0, sending 0.12590780 BTC to 1EpnssMn25sT2Doj8tGebEupni8SdiJjvk and 0.01509543 BTC to 1E14NpG1rP7zSLYcjrG4JN2iSDQfbnffrE

Unfortunately, transactionID 09bbf6...8cdfa0 never made it into the blockchain.  Therefore, we need that transaction from the sender's wallet to determine what it is trying to spend and why it isn't in the blockchain.

---

At this point you have an unconfirmed transaction 09bbf6...8cdfa0 that was spent to send 0.12590780 BTC to 1EpnssMn25sT2Doj8tGebEupni8SdiJjvk

Then the recipient of that transaction created an unconfirmed transaction 17392d...015b92 that spent the 0.12590780 BTC to send 0.02262079 BTC to 1MorjW7nxrnACk29QtomrrQSD3kXnWaddT

We are now trying to figure out why 09bbf6...8cdfa0 is unconfirmed, which is why we need the command:

getrawtransaction 09bbf633bf202cea19563b1f779ce70616ad33accf668d01dc173e45be8cdfa0

As Automatic has stated, this is likely going to be a long chain of transactions that all spent unconfirmed outputs.  Eventually, it will likely lead back to a transaction whose input was already spent elsewhere either due to transaction malleability or fraud.

getrawtransaction 09bbf633bf202cea19563b1f779ce70616ad33accf668d01dc173e45be8cdfa0

0100000001ddc28640103680027edbdfdbd77105f485d4208f73866a63ba8cddd28f04dab001000 0006c493046022100b19653b5d9d8934b228eabf6cda25a9c958e91f21c32dfb77a9e1211451a70 c6022100c09fc3eb8899e3530d70a1c8c2dcbdd6db97002a94971b20b2f4f8c80a574c140121032 8863f2cfff690200b62f3aa4ddebe4d4cc673e0e2057207096aba3711cb9036ffffffff02e62112 00000000001976a91492c05c2830312041bf809948b4634cdd56d5685c88ac734ed700000000001 976a914a70cfb418ff7e76bd819bc125848c4cb5b40bc4988ac00000000

This is getting to be quite a long list of un-confirmable transactions.  Whoever sent you this transaction REALLY needs to learn not to spend unconfirmed outputs.  They appear to have a whole bunch of transactions that they are going to have to fix for a whole bunch of people:

So far we have:

09bbf633bf202cea19563b1f779ce70616ad33accf668d01dc173e45be8cdfa0 which attempts to spend an output from non-existent b0da048fd2dd8cba636a86738f20d485f40571d7dbdfdb7e028036104086c2dd
sending:
0.01188326 BTC to 1ENx6Qz8XCfCZFrMcQB6EX8T5d4r3R9ke2 (someone else receiving an unconfirmed transaction from this guy)
0.14110323 BTC to 1GEHQ1EMUEqDovTVzj9r5UiuKg5h9pgY2y (unconfirmed change)

17392d74a8dcf0ddec3183664bc6c564ca69224c4eb0b07cd774dccc6b015b92 which attempts to spend the 0.14110323 BTC output from non-existent 09bbf633bf202cea19563b1f779ce70616ad33accf668d01dc173e45be8cdfa0
sending:
0.01509543 BTC to 1E14NpG1rP7zSLYcjrG4JN2iSDQfbnffrE (someone else receiving an unconfirmed transaction from this guy)
0.12590780 BTC to 1EpnssMn25sT2Doj8tGebEupni8SdiJjvk (unconfirmed change)

0d32dec3feea7f48d2b7b7ae99686e48403ea9f7f135688c9d2547aa75998fb0 which attempts to spend the 0.12590780 BTC output from non-existent 17392d74a8dcf0ddec3183664bc6c564ca69224c4eb0b07cd774dccc6b015b92
sending:
0.02262079 BTC to 1MorjW7nxrnACk29QtomrrQSD3kXnWaddT (an unconfirmed transaction to you)
0.10318701 BTC to 19Kz33UpsnQhBKAWQukQFwvxKFZh7XSnqi (unconfirmed change)


Now we'll need:

To determine why b0da048fd2dd8cba636a86738f20d485f40571d7dbdfdb7e028036104086c2dd doesn't exist.

I'm beginning to become concerned that he may have sent dozens of transactions that all spent unconfirmed outputs. It'll be interesting to see how far back this chain goes.

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

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
https://i.imgur.com/sCtSZLb.png

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

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.

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":-
https://i.imgur.com/0Rrd4hM.png

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

or


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

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:

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

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.

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.

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

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?

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

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

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?

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.

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.

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.

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!