Topic: Transaction is back after -zapwallettxes (Read 1780 times)
Just for info for others, what i did was started Bitcoin-qt with -zapwallettxs which cleared the unconfirmed transaction from my wallet, i then just sent the full balance to another address which fixed it. Result
-snip-
Great reply Shorena, thank you. I will PM you later with the transaction ID, or is it the raw data you would need after i do a getrawtransaction ? Although i am starting to think that it would never be confirmed anyway as the fee is really low, so i might just stop it.
Great reply Shorena, thank you. I will PM you later with the transaction ID, or is it the raw data you would need after i do a getrawtransaction ? Although i am starting to think that it would never be confirmed anyway as the fee is really low, so i might just stop it.
TX ID should be fine, it currently sees ~65k unconfirmed TXs yours should be among them. I could also rebroadcast the replacement whichever you prefer (Id probably need the raw TX in this case though).
Thanks for the offer i will get back to ya, i'm currently gonna just let it run and see if it ever confirms. What is the command to rebroadcast a transaction?
Maybe a bit late now....
Rightclick on the TX in the overview and select Copy raw transaction. In the console enter sendrawtransaction and paste the raw behind it.
-snip-
Great reply Shorena, thank you. I will PM you later with the transaction ID, or is it the raw data you would need after i do a getrawtransaction ? Although i am starting to think that it would never be confirmed anyway as the fee is really low, so i might just stop it.
Great reply Shorena, thank you. I will PM you later with the transaction ID, or is it the raw data you would need after i do a getrawtransaction ? Although i am starting to think that it would never be confirmed anyway as the fee is really low, so i might just stop it.
TX ID should be fine, it currently sees ~65k unconfirmed TXs yours should be among them. I could also rebroadcast the replacement whichever you prefer (Id probably need the raw TX in this case though).
Thanks for the offer i will get back to ya, i'm currently gonna just let it run and see if it ever confirms. What is the command to rebroadcast a transaction?
-snip-
Great reply Shorena, thank you. I will PM you later with the transaction ID, or is it the raw data you would need after i do a getrawtransaction ? Although i am starting to think that it would never be confirmed anyway as the fee is really low, so i might just stop it.
Great reply Shorena, thank you. I will PM you later with the transaction ID, or is it the raw data you would need after i do a getrawtransaction ? Although i am starting to think that it would never be confirmed anyway as the fee is really low, so i might just stop it.
TX ID should be fine, it currently sees ~65k unconfirmed TXs yours should be among them. I could also rebroadcast the replacement whichever you prefer (Id probably need the raw TX in this case though).
-snip-
Ok so i now have this transaction awaiting confirmation for 4 days or so, if i was to zapwallet now and then send my full balance (with a great fee), would my core client allow the transaction
Ok so i now have this transaction awaiting confirmation for 4 days or so, if i was to zapwallet now and then send my full balance (with a great fee), would my core client allow the transaction
Yes.
and what would happen at other nodes who see this second transaction?
Depends, either the other node knows about your previous unconfirmed transaction (A) or not (B).
In case A, your new transaction would be refused by the node as invalid and not propagated further. In case B the node would accept the TX into its mempool (assume it does not violate any other rules) and propagte it to all other connected nodes.
Since the default setting for bitcoin core (and unlimited?) nodes is to forget about a transaction after 72 hours, I think you should try this. To further improve your chances to find nodes where case B applies you can rebroadcast the transaction periodically and/or post it raw[1] here so others can do the same for you. If you PM me I can let my node rebroadcast it.
[1] I think there is a GUI way to do this, but I am not sure atm. You can just open the dev console (via Help) and put getrawtransaction followed by your new transaction ID. What you get as return is what your client would normally broadcast on its own.
Great reply Shorena, thank you. I will PM you later with the transaction ID, or is it the raw data you would need after i do a getrawtransaction ? Although i am starting to think that it would never be confirmed anyway as the fee is really low, so i might just stop it.
-snip-
Ok so i now have this transaction awaiting confirmation for 4 days or so, if i was to zapwallet now and then send my full balance (with a great fee), would my core client allow the transaction
Ok so i now have this transaction awaiting confirmation for 4 days or so, if i was to zapwallet now and then send my full balance (with a great fee), would my core client allow the transaction
Yes.
and what would happen at other nodes who see this second transaction?
Depends, either the other node knows about your previous unconfirmed transaction (A) or not (B).
In case A, your new transaction would be refused by the node as invalid and not propagated further. In case B the node would accept the TX into its mempool (assume it does not violate any other rules) and propagte it to all other connected nodes.
Since the default setting for bitcoin core (and unlimited?) nodes is to forget about a transaction after 72 hours, I think you should try this. To further improve your chances to find nodes where case B applies you can rebroadcast the transaction periodically and/or post it raw[1] here so others can do the same for you. If you PM me I can let my node rebroadcast it.
[1] I think there is a GUI way to do this, but I am not sure atm. You can just open the dev console (via Help) and put getrawtransaction followed by your new transaction ID. What you get as return is what your client would normally broadcast on its own.
Quote
Potentially forever, unless a conflicting transaction is confirmed.
So if i was to -zapwallettxes and then send all funds to another address with a good fee, that would solve the issue ?
If/when it confirms? Yes.
Would i be right in saying that this is a way that a fraudster could deceive people into sending goods and then carryout this procedure to actually send the funds elsewhere? is this technically a double spend?
Its not technically a double-spend, but its called that. Due to how bitcoin works, coins can never be spend (and confirmed) twice. Using coins that are already used in an unconfirmed transaction is possible, but not easy. Keep in mind you can remove the TX from your node (zapwallet), but not from all other nodes. Every node that knows about the initial transaction would refuse the double spend as invalid. An attack would need to trick around that and the attack can easily be mitigated by waiting for a single confirmation.
Ok so i now have this transaction awaiting confirmation for 4 days or so, if i was to zapwallet now and then send my full balance (with a great fee), would my core client allow the transaction and what would happen at other nodes who see this second transaction?
Quote
Potentially forever, unless a conflicting transaction is confirmed.
So if i was to -zapwallettxes and then send all funds to another address with a good fee, that would solve the issue ?
If/when it confirms? Yes.
Would i be right in saying that this is a way that a fraudster could deceive people into sending goods and then carryout this procedure to actually send the funds elsewhere? is this technically a double spend?
Its not technically a double-spend, but its called that. Due to how bitcoin works, coins can never be spend (and confirmed) twice. Using coins that are already used in an unconfirmed transaction is possible, but not easy. Keep in mind you can remove the TX from your node (zapwallet), but not from all other nodes. Every node that knows about the initial transaction would refuse the double spend as invalid. An attack would need to trick around that and the attack can easily be mitigated by waiting for a single confirmation.
Quote
Potentially forever, unless a conflicting transaction is confirmed.
So if i was to -zapwallettxes and then send all funds to another address with a good fee, that would solve the issue ?
If/when it confirms? Yes.
Would i be right in saying that this is a way that a fraudster could deceive people into sending goods and then carryout this procedure to actually send the funds elsewhere? is this technically a double spend?
Quote
Potentially forever, unless a conflicting transaction is confirmed.
So if i was to -zapwallettxes and then send all funds to another address with a good fee, that would solve the issue ?
If/when it confirms? Yes.
Quote
Potentially forever, unless a conflicting transaction is confirmed.
So if i was to -zapwallettxes and then send all funds to another address with a good fee, that would solve the issue ?
The transaction will still exist on the mempool of other nodes. The transaction is however, removed from your wallet and mempool. Can you find it o the block explorer?
Try this again after a while and it should work if no one else is rebroadcasting it.
Try this again after a while and it should work if no one else is rebroadcasting it.
try to resend via bitcoinj wallet check this out here: https://github.com/BitcoinJar/BitcoinJ/releases/tag/v1.4.8
so what i am wondering is did another node then tell my node about this transaction again?
Yes.and how long could other nodes keep this transaction in their mempool?
Potentially forever, unless a conflicting transaction is confirmed.
Hi i sent a transaction 4 days ago and yesterday i started core with -zapwallettxes. this morning its back unconfirmed again. Now i know that when i wipe it from my mempool that dosnt mean it is wiped from other nodes who have already seen it. so what i am wondering is did another node then tell my node about this transaction again? and how long could other nodes keep this transaction in their mempool?
thanks
thanks
Jump to: