edit: oddly enough it said they were sent and floated in limbo (neither on the receiving nor the sending wallet) and now they’re back in the original one despite the fact that I completed a transaction successfully… Peppercorns have landed
Peercoins don’t just disappear. What was the public key of the sending address(es)? You can track the activity of any address in a blockchain explorer such as http://ppc.blockr.io/.
[quote=“deliciousowl, post:1, topic:2574”]Today I had 320+ Peercoins in my wallet and i sent them to PJABEC3gn6qQkKRwogMcyXHBg4RspER8no. They never showed up, and now they’re not showing up in my wallet either.
No wonder the price is crashing. Peepee coin cant even keep its transactions in order.[/quote]
Easy there… take a deep breath! … everything will be ok.
Now, since it’s the client you’re having problems with, please provide the following:
Client version
Transaction ID
Check if client is synced on both ends wallets (sender and receiver)
This is the information needed to investigate the difficulties you’re having. Let’s be constructive in finding the answer :)…
Peppercorns don’t disappear unless you put them in as transaction fees and even as transaction fees we can still know that from the blockchain. They can always be tracked given that we keep our clients up to date.
That wouldn’t be the issue, either, because you cannot (using the client) make a change to the amount that you pay in fees. It’s based solely on the size data used to create the output transaction. There’s a field in the preferences that appears like you can make the change, but I’m almost certain that the MIN_TX_FEE is calculated independently and that’s just a vestigial UI component from the original Bitcoin fork.
@deliciousowl – Can you please provide the address that you sent the 300 peercoins from?
Do you have the problem transaction in the UI’s transaction list? If it’s there but with 0 confirmation, the client should automatically resend the transaction to network periodically. If it’s not in the transaction list, you can do a few things to first look into the problem:
Go to help -> debug window -> console
listtransactions
you should be able to see the unconfirmed send.
getinfo
this shows your client version and number of connections to the network.
If you still have issue with your wallet, first thing you do is to backup wallet. If client has corruption issues, the coins are usually recoverable, so long as you still have the keys inside wallet or from a backup wallet.
Quote of the day, right there. Gotta love autocorrect. 
I guess the peppercorns were sent, and it confirmed that they were sent. But now they’re back in the wallet. Ah those darn Peppercorns!! :’( sorry guys. I guess the transaction was reversed somehow, or never occurred even though it showed that it did? I was using 0.4
You should rename the thread title to “did not eat” so that future forum viewers will know that the Peercoin client isn’t that hungry after all!
Or at least change it to “Peercoin client ate my 300 peppercorns”.
Fixed
If the transaction was sent successfully it shouldn’t be ‘reversed’. Doublecheck your transaction list and also ‘listtransactions’ I mentioned earlier, to make sure the transaction did not happen in your wallet.
Are you sure the UI did report a successful send? Typically UI asks there is a transaction fee and whether you want to proceed, before it actually processed the transaction, if the send amount plus transaction fee exceed your total balance the send should fail with some error message. If the send failed, the balance should never be deducted. Did you ever see your UI balance reduced by the send amount?
[quote=“Sunny King, post:6, topic:2574”]Do you have the problem transaction in the UI’s transaction list? If it’s there but with 0 confirmation, the client should automatically resend the transaction to network periodically. If it’s not in the transaction list, you can do a few things to first look into the problem:
Go to help -> debug window -> console
listtransactions
you should be able to see the unconfirmed send.
getinfo
this shows your client version and number of connections to the network.
If you still have issue with your wallet, first thing you do is to backup wallet. If client has corruption issues, the coins are usually recoverable, so long as you still have the keys inside wallet or from a backup wallet.[/quote]
Hey sunny… your response got me thinking. If a transaction fails, the client attempts to resend it again and again until it’s a accepted, correct? Does that also apply to the rpc command sendrawtransaction or do I as a third party developer need to check for the transaction and keep resending when it’s not acquired? I know it’s currently not implemented in the client but this would give insight about other coins as well and help me in my development
Raw transactions are treated same as transactions received on the network, that is, if the transaction is signed by a key in your wallet, then it will also be recorded a copy in your wallet file. It also resides in memory pool and gets sent to other nodes. But if the node is experiencing connection problems, there is no guarantee that it would be resent to network, unless it’s a transaction of your own thus recorded in your wallet file. You can use listtransactions to verify the status of a transaction sent by yourself.
Raw transactions are treated same as transactions received on the network, that is, if the transaction is signed by a key in your wallet, then it will also be recorded a copy in your wallet file. It also resides in memory pool and gets sent to other nodes. But if the node is experiencing connection problems, there is no guarantee that it would be resent to network, unless it’s a transaction of your own thus recorded in your wallet file. You can use listtransactions to verify the status of a transaction sent by yourself.[/quote]
Thank you for your prompt reply Sunny! This is very helpful