Pages:
Author

Topic: Stuck transactions - possibly new attack? (Read 2942 times)

legendary
Activity: 3472
Merit: 4801
February 15, 2014, 09:25:25 AM
#26
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).

But will it figure out how to adjust the "accounts" that the OP is using in the way that he wants them updated?
hero member
Activity: 588
Merit: 520
February 15, 2014, 08:54:17 AM
#25
I have followed the steps previously pointed out and after deletion of all transactions, overall BTC balance was less, but when checking balance of all accounts -> they all had MORE in. So I decided to go forward and I resent stuck transactions. It looks like everything is fine now.

But I am still wondering why pywallet with command to delete all transactions messed accounts. Perhaps when deleting all transactions, internal "move" transactions are also deleted?
hero member
Activity: 588
Merit: 520
February 14, 2014, 04:59:21 PM
#24
I am trying to figure out the best strategy on how to salvage this.

I am scared of loosing some BTCs in the process.

What I was thinking I should do is following:
- wait for all legit transactions to get confirmed
- stop website from communicating with bitcoin-qt
- identify all legit non-confirming outgoing transactions (remember account + destination addr + amount + txid)
- use 'listaccounts' command and save balances of all customers
- identify all malled transactions (remember txid for each)
- close bitcoin-qt
- remove malled transactions and all legit non-confirming outgoing transactions using pywallet - one by one
- open bitcoin-qt
- use 'listaccounts' - if deletion of transactions went all ok, then some accounts will have higher balance than before - if one account has less, then something went wrong (is this assumption correct?)
- resend all previously saved legit non-confirming transactions

Can someone experienced with bitcoin accounts tell me if this procedure is correct?
hero member
Activity: 588
Merit: 520
February 14, 2014, 04:28:52 PM
#23
I just checked out something; I issued getaccounts and did sum on balance of all accounts. The result is that summarized balance is far less than what is bitcoin-qt showing me on first page. The difference is much more than sum of all unconfirmed transactions. Where is the catch?
hero member
Activity: 588
Merit: 520
February 14, 2014, 03:55:21 PM
#22
Okay, but will bitcoin-qt at least remove past malled transactions, and doing this correctly to keep proper account balances? Then I just need to do resends of all legit transactions that failed, right?
donator
Activity: 1218
Merit: 1079
Gerald Davis
February 14, 2014, 01:47:02 PM
#21
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).


I just saw zapwallet.  Nice solution.  Kill all tx records and then rescan to pickup only the confirmed ones. Smart.
staff
Activity: 4284
Merit: 8808
February 14, 2014, 01:28:04 PM
#20
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).
donator
Activity: 1218
Merit: 1079
Gerald Davis
February 14, 2014, 01:04:25 PM
#19
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. 
legendary
Activity: 3472
Merit: 4801
February 14, 2014, 01:01:04 PM
#18
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.
hero member
Activity: 588
Merit: 520
February 14, 2014, 12:57:22 PM
#17
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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
February 14, 2014, 12:46:09 PM
#16
It is a known issue of mutated transactions. 
https://bitcointalksearch.org/topic/what-the-average-user-needs-to-know-about-transaction-mutability-460944

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


legendary
Activity: 3472
Merit: 4801
February 14, 2014, 12:40:49 PM
#15
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.
hero member
Activity: 588
Merit: 520
February 14, 2014, 12:35:26 PM
#14
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.
legendary
Activity: 3472
Merit: 4801
February 14, 2014, 12:32:38 PM
#13
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.
hero member
Activity: 588
Merit: 520
February 14, 2014, 12:25:11 PM
#12
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.
legendary
Activity: 3472
Merit: 4801
February 14, 2014, 12:22:57 PM
#11
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.
hero member
Activity: 588
Merit: 520
February 14, 2014, 12:21:15 PM
#10
Edited my post, I could find it. Looks like now I have to track this one back like the one before right?
legendary
Activity: 3472
Merit: 4801
February 14, 2014, 12:20:46 PM
#9
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.
hero member
Activity: 588
Merit: 520
February 14, 2014, 12:20:11 PM
#8
I can see the issue yes, one of inputs is obviously non valid transaction that was created god knows where.
hero member
Activity: 588
Merit: 520
February 14, 2014, 12:18:37 PM
#7
Quote
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"
]
}
}
]
}
Pages:
Jump to: