Every double-spending is an address reuse but not every address-reuse is a double-spending.
Let's say you have an address with a balance of 100i
You send 100i from the address to another address and 100i from the address to yet another address.
You send 40i to from the address to another address and 70i from the address to yet another ...
The best way, to get your transaction through is to run your own full node on a seperate Server. This makes transactions faster and gives you more control.
However, if you don't run your own full node, I recommend you to check https://iota.dance/nodes and choose the first/highest node (which is the public node providing the best chances, because of the lowes ...
You are right: it's easy to implement a wallet to steal user's seed.
If you are a developer, you can:
write your own wallet and trusting your own code.
read and understand the code written by a third party and put your trust in it.
If you aren't a developer, you must put your trust in someone else's code. You must educate yourself by reading forums and ...
It has been observed that the more addresses in your wallet, the longer it takes for your computer to retrieve all associated addresses from the Tangle.
The new wallet should remedy this -- it will be stateful, and store your previous addresses locally, so you don't have to re-retrieve them every single time you log in.
A transaction has not failed even if it does not confirm. You should never make a new transaction, but replay the first one until it confirms. The only time a transaction will not confirm, is if the signature is invalid (not possible to do with wallet), or if the address (or one of them) you spend from have a lower balance than the transaction requires.
The Android wallet tries to retrieve latest transactions from http://iota.cool—if that fails, this notification is shown. This site seems to be down at the moment. But apart from the fact that the explorer view does not show any recent transactions, the wallet should still work fine.
Here is the source code that does this on github.
You cannot get parts of the private key using reattachments. To understand why, let's see how signing works.
First of all, there is an unsigned bundle consisting out of several transactins. To sign it, we first need to calculate the bundle hash. Only the address, value, obsolete tag, timestamp, current index and last index are used. Note, nonce, trunk/...
From your comment on mihi's question I saw that this is your address.
And I think the funds were stolen:
If you follow the outgoing transactions (again and again and again) you end up at these 3 addresses:
The thief tried to move the funds from address to address with different inputs ...
A wallet should be open source -- this way, it can be vetted by the community to ensure there are no loopholes or trojans.
Aside from that, you should look to the community and determine which wallets are used, for what reasons, where they come from, and their track record to determine which wallet you want to use.
The action that will compromise your security is sending a transaction from the same address twice.
That is what address reuse is: sending a transaction from the same address twice.
You CAN do this by double spending, which is trying to send the same IOTA multiple times while it is still pending. But you can also re-use your address by sending, receiving ...
If you have 1i in another wallet (not related to the seed with your 2i address) - for example wallet C -, you can use that wallet to send 1i to the address of wallet A that currently has the 2i. Afterwards (when this transaction is confirmed), your balance of that address will be 3i, so you can reattach the pending 3i transaction again.
However, you should ...
Do you want to share your address the tokens were "stolen" from? To troubleshoot this, it is generally helpful to know the address where the IOTA have resided on last.
To avoid problems with the node, switch it and see if it changes anything. You can also compare the milestone numbers in the status bar with other nodes to see if a node is lagging behind ...