When you do a transaction you always spend ALL of the coins in that address, part of the money goes to whoever you're paying, and there rest is returned to you an a new 'change' address. (This helps your anonymity as someone watching cannot tell which amount you spent and which amount you kept.)
Before transaction:
Address1: 9000
Address2: 0
After transaction:
Address1: 0
Address2: 1
Address3: 8999
It sounds like you have wallet.dat that contains the private keys for Address1 and Address2, but not Address3.
The problem seems to be he didn't backup after he initiated the transaction. It's news to me (and apparently a lot of other people) that you can lose bitcoins in this scenario.
One proposed solution is to pre-generate some number of addresses that get stored in your wallet long before you actually use them, so they'll get backed up.
It turns out this happened a year ago and the proposed fix I mentioned has already been implemented:
"Since this post a year ago, this feature has been implemented as keypools=100. Personally, I think it is a bad idea and does not address the problem, only pushes it off to the 101st address. At that point, users will come to expect certain backup behavior and then one day (presumably when they have more 'real' rather than 'play' money) it doesn't work as expected.
Unless the pool is recycled (change is returned to a random or cycle of addresses) then this is far more dangerous.
I propose, instead, what is expected. The change should be returned to the same address that the BitCoins were sent from.
I understand this decreases deniability/anonymity. But if someone really is paranoid, they should really be laundering money through multiple addresses in random amounts at random intervals. Sending change to a new address is just an obvious 'paper trail' considering all transactions are public, it doesn't take genius investigator to follow the money."
Thanks for the explanation and link. Reading it was like a train wreck...it's awful but you just can't look away.
I don't see how that can be considered in any way a reasonable limitation of the system. I had no idea the "coins" were so fragile.
Every time I think, "Hey, maybe it's time to start accepting bitcoin for our software. It can't hurt, and might even help spur adoption of new digital currencies." Something crazy comes along that makes me think bitcoin isn't so well thought out, after all. I was already a little worried about the "money" being stored on our world-facing system. I'd already assumed I would need to transfer to a private account every day or something to insure that a break-in of our web server (which has never happened in our 6 years of running it, but I know enough about system security to know that a determined attacker could eventually find a way in; which is why we don't store credit card data, software signing keys, or anything else particular sensitive on that server). But, this makes me think bitcoin, as implemented, all but guarantees coin loss, given enough time using the system...possibly very large losses, as in this case.
Seems that a system crash during a transaction would also lead to the same results. And even one bit of data corruption during saving data would do the same.
But, I guess this is the pain one experiences being on the bleeding edge. It wouldn't be called that, if somebody didn't bleed now and then.
What's stopping a malicious client from just generating a lot of tiny transactions to fill up the block chain and overwhelm all the other clients that perform the verifications?
I understand that the current database with all the transactions takes up a few hundred MB (and this is why it can take a while to verify a bitcoin transaction).
Couldn't a small number of clients attack the currency by DOSing the network with transactions?
I believe the idea is that a small transaction fee will be expected by the majority of miners, which will make a flood of transactions costly.
Miners are free to include/exclude your transaction in their block regardless of whether a transaction fee was included. If the majority rejects transactions without a fee then it will take a longer time for the transaction to be included in a block.
Comments
From the forum post (http://forum.bitcoin.org/index.php?topic=782.0):
When you do a transaction you always spend ALL of the coins in that address, part of the money goes to whoever you're paying, and there rest is returned to you an a new 'change' address. (This helps your anonymity as someone watching cannot tell which amount you spent and which amount you kept.)
Before transaction:
Address1: 9000
Address2: 0
After transaction:
Address1: 0
Address2: 1
Address3: 8999
It sounds like you have wallet.dat that contains the private keys for Address1 and Address2, but not Address3.
The problem seems to be he didn't backup after he initiated the transaction. It's news to me (and apparently a lot of other people) that you can lose bitcoins in this scenario.
One proposed solution is to pre-generate some number of addresses that get stored in your wallet long before you actually use them, so they'll get backed up.
It turns out this happened a year ago and the proposed fix I mentioned has already been implemented:
"Since this post a year ago, this feature has been implemented as keypools=100. Personally, I think it is a bad idea and does not address the problem, only pushes it off to the 101st address. At that point, users will come to expect certain backup behavior and then one day (presumably when they have more 'real' rather than 'play' money) it doesn't work as expected.
Unless the pool is recycled (change is returned to a random or cycle of addresses) then this is far more dangerous.
I propose, instead, what is expected. The change should be returned to the same address that the BitCoins were sent from.
I understand this decreases deniability/anonymity. But if someone really is paranoid, they should really be laundering money through multiple addresses in random amounts at random intervals. Sending change to a new address is just an obvious 'paper trail' considering all transactions are public, it doesn't take genius investigator to follow the money."
Thanks for the explanation and link. Reading it was like a train wreck...it's awful but you just can't look away.
I don't see how that can be considered in any way a reasonable limitation of the system. I had no idea the "coins" were so fragile.
Every time I think, "Hey, maybe it's time to start accepting bitcoin for our software. It can't hurt, and might even help spur adoption of new digital currencies." Something crazy comes along that makes me think bitcoin isn't so well thought out, after all. I was already a little worried about the "money" being stored on our world-facing system. I'd already assumed I would need to transfer to a private account every day or something to insure that a break-in of our web server (which has never happened in our 6 years of running it, but I know enough about system security to know that a determined attacker could eventually find a way in; which is why we don't store credit card data, software signing keys, or anything else particular sensitive on that server). But, this makes me think bitcoin, as implemented, all but guarantees coin loss, given enough time using the system...possibly very large losses, as in this case.
Seems that a system crash during a transaction would also lead to the same results. And even one bit of data corruption during saving data would do the same.
But, I guess this is the pain one experiences being on the bleeding edge. It wouldn't be called that, if somebody didn't bleed now and then.
What's stopping a malicious client from just generating a lot of tiny transactions to fill up the block chain and overwhelm all the other clients that perform the verifications?
I understand that the current database with all the transactions takes up a few hundred MB (and this is why it can take a while to verify a bitcoin transaction).
Couldn't a small number of clients attack the currency by DOSing the network with transactions?
Edit: found this, I guess they know it "might be" a problem https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_%28D...
I believe the idea is that a small transaction fee will be expected by the majority of miners, which will make a flood of transactions costly.
Miners are free to include/exclude your transaction in their block regardless of whether a transaction fee was included. If the majority rejects transactions without a fee then it will take a longer time for the transaction to be included in a block.