Stuck transactions - possibly new attack?

[djeZo]

Is there another form of attack going on bitcoin network right now?

I have several outgoing transactions (not malled ones - legit, created by my bitcoin-qt client) that are never confirming. Fee was paid for them, TXID cannot be found on blockchain. I have never seen this before. But now they are poping up after incident with malled transactions. Worth mentioning is that some of these are being sent to same address and having same amount - maybe there are some nodes in bitcoin network that are filtering malled transactions the wrong way and filtering out my legit transactions now?

How should I proceed in solving this? I still have bunch of malled transactions (but these are dating few days back). The accounts/addresses of these new "stucks" are not related to past malled ones.

Would be the proper way to clean up stuck transactions and perform resends?

[coastermonger]

care to post any more info on these?

[djeZo]

I can give you TXIDs, but you won't be able to find them... so whats the point of it?

I am using bitcoin-qt, RPC API for everything related to BTC handling, and of course, integrated accounts in bitcoin client.

I checked bunch of transactions that were made by same customer (person X) going to same rig provider (person Y), and were only few or even less minutes appart. There was total of 8 transactions, 6 were at the end confirmed, 2 are still not and pending (since 12.2.2014 20:45 CET time). After these transactions, same customer hired other rigs some hours later and these transactions were then confirmed. Does that mean that it is safe to assume these 2 non-confirmed transactions will never be confirmed and should be deleted and resent?

[klondike_bar]

I can give you TXIDs, but you won't be able to find them... so whats the point of it?

I am using bitcoin-qt, RPC API for everything related to BTC handling, and of course, integrated accounts in bitcoin client.

I checked bunch of transactions that were made by same customer (person X) going to same rig provider (person Y), and were only few or even less minutes appart. There was total of 8 transactions, 6 were at the end confirmed, 2 are still not and pending (since 12.2.2014 20:45 CET time). After these transactions, same customer hired other rigs some hours later and these transactions were then confirmed. Does that mean that it is safe to assume these 2 non-confirmed transactions will never be confirmed and should be deleted and resent?

I am having a similar issue where a txid cannot be found on blockchain even after almost 10 minutes. I had a malled transaction before, so perhaps my address balances are all out of sync.

what can/should I do?

[thenoblebot]

I think the transactions are being mutated intentionally (although it does happen once in a while in normal course). I have made a (tentative) proposal here (https://bitcointalk.org/index.php?topic=463350.0)of how to go about identifying the pool responsible for it, IF it is being done by a pool at all. Once we can identify it then that should solve the majority of such problems.

[DannyHamilton]

I can give you TXIDs, but you won't be able to find them... so whats the point of it?

I am using bitcoin-qt, RPC API for everything related to BTC handling, and of course, integrated accounts in bitcoin client.

Issue a "getrawtransaction" with the transactionID that you are having a problem with.

Post the results of the getrawtransaction here.

We can then use "decoderawtransaction" with our own bitcoin wallets to see what the inputs and outputs are.  Analyzing this will likely indicate why your wallet is unable to broadcast the transaction.

[djeZo]

18:16:55

getrawtransaction 1a44d2878b9b0548c71008a2f98c42bfe4785b4ce23c58f92821392db8a799c3 1


18:16:55

{
"hex" : "0100000002014936564df3e0673448a5021296a8c81fd371f38a5b402d41095ce258416fdf01000 0006b483045022100960ba73278dac1aef7fb33034f8baf0831db82384ae495b4f845ac7cd64671 7102200a1525cbd345b3766451da650371b677f9f1acbd43d9b186d2d7d5d1044bc616012102712 efdcd8b53634fc1a1382d5675890ae28024c01cb194d3e47f855e70c9ee7affffffffdab03cdea5 7f8ba22447dfa8cd9a90752f58e32900b9c453b4510c5aacc04aea000000006b483045022100b5f ff05694dcbaf1186a9fe0f3ab0f54d0e0ec2952aee4f01b50cd7f0288dce4022051860923b22939 78f43322af7dac562c271626116181d98ec4bdb627fc9c8e2e01210298f52d8a30a7e1e1e75cd1b f55c7bbd7d4f03a83480ed3391647de131fa7733fffffffff0240bc0300000000001976a9148e73 0fc1b480a02209cb651c87fc2bf49df4c8fa88ac41131d00000000001976a91462cf0d9ffbafec1 17a0bf0718d00030796905fdc88ac00000000",
"txid" : "1a44d2878b9b0548c71008a2f98c42bfe4785b4ce23c58f92821392db8a799c3",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "df6f4158e25c09412d405b8af371d31fc8a8961202a5483467e0f34d56364901",
"vout" : 1,
"scriptSig" : {
"asm" : "3045022100960ba73278dac1aef7fb33034f8baf0831db82384ae495b4f845ac7cd646717102200 a1525cbd345b3766451da650371b677f9f1acbd43d9b186d2d7d5d1044bc61601 02712efdcd8b53634fc1a1382d5675890ae28024c01cb194d3e47f855e70c9ee7a",
"hex" : "483045022100960ba73278dac1aef7fb33034f8baf0831db82384ae495b4f845ac7cd6467171022 00a1525cbd345b3766451da650371b677f9f1acbd43d9b186d2d7d5d1044bc616012102712efdcd 8b53634fc1a1382d5675890ae28024c01cb194d3e47f855e70c9ee7a"
},
"sequence" : 4294967295
},
{
"txid" : "ea4ac0ac5a0c51b453c4b90029e3582f75909acda8df4724a28b7fa5de3cb0da",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100b5fff05694dcbaf1186a9fe0f3ab0f54d0e0ec2952aee4f01b50cd7f0288dce402205 1860923b2293978f43322af7dac562c271626116181d98ec4bdb627fc9c8e2e01 0298f52d8a30a7e1e1e75cd1bf55c7bbd7d4f03a83480ed3391647de131fa7733f",
"hex" : "483045022100b5fff05694dcbaf1186a9fe0f3ab0f54d0e0ec2952aee4f01b50cd7f0288dce4022 051860923b2293978f43322af7dac562c271626116181d98ec4bdb627fc9c8e2e01210298f52d8a 30a7e1e1e75cd1bf55c7bbd7d4f03a83480ed3391647de131fa7733f"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.00244800,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 8e730fc1b480a02209cb651c87fc2bf49df4c8fa OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9148e730fc1b480a02209cb651c87fc2bf49df4c8fa88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1DzCnrgNS3MACNU5uAZ37AKA4nTV27yk5F"
]
}
},
{
"value" : 0.01905473,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 62cf0d9ffbafec117a0bf0718d00030796905fdc OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a91462cf0d9ffbafec117a0bf0718d00030796905fdc88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1A1TG7MJKtbX92Guijo6dg87JnSK9wAvtF"
]
}
}
]
}

[djeZo]

I can see the issue yes, one of inputs is obviously non valid transaction that was created god knows where.

[DannyHamilton]

I can see the issue yes, one of inputs is obviously non valid transaction that was created god knows where, can't find it in my bitcoin client either...

Glad to help.

[djeZo]

Edited my post, I could find it. Looks like now I have to track this one back like the one before right?

[DannyHamilton]

Edited my post, I could find it. Looks like now I have to track this one back like the one before right?

Which you will only be able to do if that invalid output (that is being used as an input in this transaction) was created by this wallet. This is likely if you are not creating rawtransactions to spend unconfirmed outputs that you receive from someone else.

Otherwise, it is a double-spend attempt from someone else, and you have to figure out who sent you the bad output that you then tried to spend.  This can only happen if you are spending unconfirmed outputs.

[djeZo]

Edited my post, I could find it. Looks like now I have to track this one back like the one before right?

Which you will only be able to do if that invalid output (that is being used as an input in this transaction) was created by this wallet.

Otherwise, it is a double-spend attempt from someone else, and you have to figure out who sent you the bad output that you then tried to spend.

Well, obviously, these transactions are related to previously malled ones that I still have in the wallet? Or is my assumption wrong?

All other spending is only possible with min 6 confirmations.

[DannyHamilton]

Edited my post, I could find it. Looks like now I have to track this one back like the one before right?

Which you will only be able to do if that invalid output (that is being used as an input in this transaction) was created by this wallet.

Otherwise, it is a double-spend attempt from someone else, and you have to figure out who sent you the bad output that you then tried to spend.

Well, obviously, these transactions are related to previously malled ones that I still have in the wallet? Or is my assumption wrong?

You are almost certainly correct, but depending on how you are using the wallet (are you creating raw transactions?), there may be a small possibility that they not related to the "malled" ones.

All other spending is only possible with min 6 confirmations.

If you are creating raw transactions, then it is possible to spend with 0 confirmations.  If you have imported your private keys from or into any other wallet, it is possible to "double spend" against yourself accidentally.

[djeZo]

No, I am not using raw transactions. All outgoing transactions are formed by calling sendFrom API with 6 min confirmations. No keys imported, all were generated by this same wallet.

[DannyHamilton]

No, I am not using raw transactions. All outgoing transactions are formed by calling sendFrom API with 6 min confirmations. No keys imported, all were generated by this same wallet.

Then yes, these transactions are all transaction that attempted to spend a 0 confirmation "change" output from some other transaction.  If you follow the chain back far enough, you'll get to a "malled" transaction where the transactionID that was eventually confirmed was not the same as the transactionID that your wallet tried to use as an input when it spent the 0 confirmation output.

[DeathAndTaxes]

It is a known issue of mutated transactions. 
https://bitcointalk.org/index.php?topic=460944.0

The immediate fix is to delete the broken tx (using pywallet).  Make sure to make a backup first.
Then make sure the wallet is synced and all prior transactions have confirmed.
Recreate the broken transaction and it will go through this time.

In the future it would be best to ensure you do not attempt to spend unconfirmed change.  The next release of the client will have an option to ensure that doesn't happen but for now if you make sure all your prior txs are confirmed before making a new tx this can't happen (even if the prior txs are mutated).

[djeZo]

OK thank you both. I can now understand the issue better than before.

Pywallet tool did not work well for me - it messed accounts, so I cannot use that. Looks like the only solution is to wait for bitcoin client update from devs. I hope they will modify client to clear&resend these old transactions too.

[DannyHamilton]

OK thank you both. I can now understand the issue better than before.

Pywallet tool did not work well for me - it messed accounts, so I cannot use that. Looks like the only solution is to wait for bitcoin client update from devs. I hope they will modify client to clear&resend these old transactions too.

I wouldn't expect an updated client to resend the transactions.  That would be disasterous for anyone who already sent the transactions themselves.

I'm not sure if the updated client will be able to determine what you want done with the "accounts" either, but I haven't looked into that much, so I suppose it might be possible.

[DeathAndTaxes]

OK thank you both. I can now understand the issue better than before.

Pywallet tool did not work well for me - it messed accounts, so I cannot use that. Looks like the only solution is to wait for bitcoin client update from devs. I hope they will modify client to clear&resend these old transactions too.

The pull requests on github are related to removing duplicates from display and preventing the spending of unconfirmed change outputs.  It will prevent FUTURE problems but it isn't going to magically fix old problems. 

[gmaxwell]

it isn't going to magically fix old problems. 

Well, actually—

Zapwallet will fix these cases, in a kind of blunt way.

There is also a patch forthcoming that will release stuck coins (after, by default, something like 144 blocks).