Closed madmax-X closed 13 years ago
wiresharking the communications from the cliend the has of a pending transaction is never sent...bitcoin communications aren't encrypted so i would assume the hash from logcat
W/System.err(15111): 2460963 [AsyncTask #2] INFO com.google.bitcoin.core.Wallet - confirmSend of de5168779cab52dc01c5b.....
would be in a tcp dump...when i search for that hex value it is not in the wireshark stream...but no packet contains those hex values
logcat states that broadcast was sucessful
i think it is incorrectly reporting a successful broadcast...
D/Wallet (15111): Saving wallet D/Wallet (15111): Notifying BackupManager that data has changed. Should backup soon. D/Wallet (15111): Ending background task D/Wallet (15111): Downloading block chain D/Wallet (15111): discoverPeers returning 1 peers D/Wallet (15111): Starting download from new peer D/Wallet (15111): no change count is 0 and current is 0 D/Wallet (15111): Connecting to local peers D/Wallet (15111): Resending pendings transactions D/Wallet (15111): resending D/Wallet (15111): Broadcast succeeded D/Wallet (15111): Broadcast succeeded D/Wallet (15111): Broadcast succeeded W/System.err(15111): 2460963 [AsyncTask #2] INFO com.google.bitcoin.core.Wallet - confirmSend of de5168779cab52dc01c5b D/Wallet (15111): Saving wallet
i trucated the hash strings for ease of reading
i tested with version 1.0 apk and problem still persists...why are they not sending?
edit: so i got it to send but i had to fill the send amount out to the 8th decimal place...sending anything smaller than that caused it to pend/hang for days...balance was 0.10549371...sending 0.1054937 failed but sending the entire balance succeeded in seconds to my pc...version 1.0 wouldnt send probabily because of the 8decimal places in the pending request when it only supported 2
hope this helps -max
i believe the pending send not being accepted is in relationship to issue 47 of bitcoinj
http://code.google.com/p/bitcoinj/issues/detail?id=47
the bottom comment:
"And this is what happens here. The client tries to send a transaction that was built and put into the pending pool days ago."
so our bitcoins are stuck in limbo trying to submitt to an old block
can we either cancel the current pending send after x retries &| xdays? or have a way to recalc and resubmitt?
maybe a way to rebuild the wallet from the chain so it would leave out the pending transactions
these transaction i speak of are not in bitcoincharts unconfirmed list or blockexplorer so they apear to be local to the device and being rejected by all 8 peers during the resend
i have had this happen on 2 diff devices, one transaction is over a week old and the other just hit the 36hr mark
EDIT:
so im at a loss aparently bitcoin transactions are stateless so rehashing wouldnt work /* * Statelessly creates a transaction that sends the given number of nanocoins to address. The change is sent to * the first address in the wallet, so you must have added at least one key.
* This method is stateless in the sense that calling it twice with the same inputs will result in two * Transaction objects which are equal. The wallet is not updated to track its pending status or to mark the * coins as spent until confirmSend is called on the result. */
but i did try and send another .03 btc to another address and it is hanging as 'pending' as well might be a problem after the 1.1 update...ill let you know tomorrow
EDIT2: could we get a way to add a node to always use? such as -addnode=173.242.112.53 for the free transaction relay im assuming the problem lies in the reuse of small coins and a lack of a transaction fee option in the app