Lost large number of bitcoins

[gridecon]

News to me is that *all* your coins are at risk.  I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance.  Yikes.

You were right before. The reason all of his coins were lost is that he first transfered all ฿9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself ฿1, he would have only lost the smallest payment that he had previously received that was over ฿1.

I think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer.

Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to "empty your wallet" for EACH transaction. According to the description I read, when you send coins from address A in your wallet to address B externally, the transaction is actually done by sending ALL the coins out from address A, and the ones that aren't going to address B get sent to address C which is your own address - in other words, even if I'm only paying you a single bitcoin out of my 9000, I mail 1 bitcoin to you and 8999 to myself at a new address.

In other words (unless I'm confused), every transaction you make will result in your old, backed-up wallet addresses become emptied out.

[1714229201]

1714229201

[FreeMoney]

News to me is that *all* your coins are at risk.  I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance.  Yikes.

You were right before. The reason all of his coins were lost is that he first transfered all ฿9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself ฿1, he would have only lost the smallest payment that he had previously received that was over ฿1.

I think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer.

Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to "empty your wallet" for EACH transaction. According to the description I read, when you send coins from address A in your wallet to address B externally, the transaction is actually done by sending ALL the coins out from address A, and the ones that aren't going to address B get sent to address C which is your own address - in other words, even if I'm only paying you a single bitcoin out of my 9000, I mail 1 bitcoin to you and 8999 to myself at a new address.

In other words (unless I'm confused), every transaction you make will result in your old, backed-up wallet addresses become emptied out.

My understanding is that it finds an address or addresses that have at least the number of coins you want to send and sends the change to a new address.

So if he had addresses with 1000, 2000, 2500, and 3500. It would have selected one of them (the lowest one?) and sent 1 away and sent all but 1 back to a new address of his. In this case he would not lose them all, just the remainder of what was in that one address.

It appears he had only 1 address with coins in it. This is probably because he got them all from the market in one go. If that is not the case, then I don't know why he would lose them all.

[gridecon]

Ok, re-reading carefully and checking the referenced thread, I finally understand this in detail. It's not that bitcoin "empties your wallet" at each transaction - it fully empties an address used to send coins. In this particular case, the user had previously sent themselves the 9000 coins in a lump, resulting in all those coins being held at a single address.

So far as I can tell, there is no way from the GUI client to actually get at the information of what coins in your balance are held at what addresses? Given that the addresses are what is "really important" that information might be of value.

[Insti]

Your 'wallet' is more like your own personal bank
It contains many different accounts. (in Bitcoin these are called Addresses)

Each Address has a balance associated with it, how much money is in it.
Your Wallet balance is the sum of all the balances of the Addresses in your wallet.

When you perform a transaction, it empties enough Addresses to make up the required output amount, but since it has to completely empty each Address there is often money left over in this case the 'change' is returned to you at a new Address.

In this case Stone Man did a transaction that sent all the money from 700+ addresses into a single address and therefore had a wallet containing only one Address that had any money in it.

That Address/Account was emptied as part of the 1BTC transaction and the 8999 change was returned to a new Address to which he lost the private key.

If he had not consolidated all his coins into one Address, he would have lost far fewer coins.

I think the moral of the story might be: "Don't put all your eggs in one basket"

So far as I can tell, there is no way from the GUI client to actually get at the information of what coins in your balance are held at what addresses? Given that the addresses are what is "really important" that information might be of value.

No you can't find out which addresses have which balances using the current GUI.

I think it is "very important" information. 
I also think it is important to be able to chose which addresses are the source of transactions.

This is an example of why the wallet metaphor is bad.

[satoshi]

I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed.

You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup.  (like 5 seconds)

Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to "empty your wallet" for EACH transaction.

No, it doesn't usually empty your wallet with each transaction.  It uses the smallest set of coins it can find to add up to near the amount.  In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change.

[vess]

I just want to add my voice to those recommending strongly that the client have an "Accounts" Tab showing an Address and amount stored in each Account.

This would be a natural place to add backup functionality and provisos and warnings.

[joechip]

I just want to add my voice to those recommending strongly that the client have an "Accounts" Tab showing an Address and amount stored in each Account.

This would be a natural place to add backup functionality and provisos and warnings.

I will 2nd (3rd, 4th... whatever) this suggestion.  This would help the accounting tremendously.

and, stone man, wow, my condolences.

Ta,

[Ground Loop]

More than just Accounts, I'd really like total visibility into what bills are in my wallet, the specific transactions in/out, some total register view that has all the details available.  I feel like the UI is a bit dumbed down, and most of the early adopters are curious about the machinery, not just their total balance.

Just my BTC 0.02.

[llama]

There was talk a while ago about building up a sizeable list of addresses in the wallet that would be hidden but used for change for future transactions.  The benefit there is that if a user backs up his wallet and something like this happens after future transactions, his old backup will still "contain" all of the bitcoins since it actually has the addresses that change coins were sent to.

What ever happened to that idea?  I think it's a good one.

[chaord]

There was talk a while ago about building up a sizeable list of addresses in the wallet that would be hidden but used for change for future transactions.  The benefit there is that if a user backs up his wallet and something like this happens after future transactions, his old backup will still "contain" all of the bitcoins since it actually has the addresses that change coins were sent to.

What ever happened to that idea?  I think it's a good one.

I would like to promote this idea as well (or something similar).  What happened to Stone Man simply should be nearly impossible from the start, regardless of backups.

[FreeMoney]

There was talk a while ago about building up a sizeable list of addresses in the wallet that would be hidden but used for change for future transactions.  The benefit there is that if a user backs up his wallet and something like this happens after future transactions, his old backup will still "contain" all of the bitcoins since it actually has the addresses that change coins were sent to.

What ever happened to that idea?  I think it's a good one.

I would like to promote this idea as well (or something similar).  What happened to Stone Man simply should be nearly impossible from the start, regardless of backups.

You mean when you lose wallet.dat you should still have your coins? He would have been fine if he didn't erase his HD.

[netrin]

> There was talk a while ago about building up a sizeable list of addresses
> in the wallet that would be hidden but used for change for future
> transactions.  The benefit there is that if a user backs up his wallet and
> something like this happens after future transactions, his old backup
> will still "contain" all of the bitcoins since it actually has the addresses
> that change coins were sent to.
>
> What ever happened to that idea?  I think it's a good one.

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.

[caveden]

That'd be the equivalent of not having a change at all, I believe.
And, well, honestly, I don't know why it was implemented like this. Unless there's something in the protocol that forces an address to be completely spent when it's used as input, I don't see much utility in this change feature.

[casascius]

As I was perusing the source code, I got the impression that each time a key is used, the wallet is topped off to have 100 spares.  I could have understood it wrong, but if I understood it correctly, I don't think it's the 101st transaction that gets hosed... it's the 101st transaction since the backup you have.  (e.g. backup at 55 transactions, you'll get hosed if you need key #156).  Someone please correct me if I'm wrong.

[SgtSpike]

As I was perusing the source code, I got the impression that each time a key is used, the wallet is topped off to have 100 spares.  I could have understood it wrong, but if I understood it correctly, I don't think it's the 101st transaction that gets hosed... it's the 101st transaction since the backup you have.  (e.g. backup at 55 transactions, you'll get hosed if you need key #156).  Someone please correct me if I'm wrong.

You are correct.

[BookLover]

Wow , tough break:'(.  I wish I could help you .

[Maged]

Looks like this was already added to the list of known lost bitcoins. I did make a minor correction to the number, though.

[netrin]

...each time a key is used, the wallet is topped off to have 100 spares. ... I don't think it's the 101st transaction that gets hosed... it's the 101st transaction since the backup you have.

That is correct. It still sets a precedent of false expectations. First of all, aside from geeks who read the source code, the majority of users will assume that 'change' is returned to the same address. In fact, most users will not understand the distinction between addresses and wallets, particularly because the client does not present the pool of addresses or the balances per address. As soon as a user learns "phew! I can just restore from backup", they will similarly assume they can ALWAYS restore from the same backup.

In fact, that is precisely what should be DESIRED. I should be able to store a physical offline backup of my addresses in a sealed container at the bottom of the ocean. I should be able to give a sealed copy of the keys to my lawyer to be opened by my next of kin upon my death, which I hope will be a hundred years from now.

Let's not focus entirely on anonymity and encryption, while making it very difficult to hold on to our money. A cycle of 100 static RECYCLED keys is probably good enough for most casual users. Let the paranoid pre-generate a billion keys, but then keep it STATIC until the end of time. Or just use one address per wallet and let the paranoid launder their money using a predictable process.

[SgtSpike]

...each time a key is used, the wallet is topped off to have 100 spares. ... I don't think it's the 101st transaction that gets hosed... it's the 101st transaction since the backup you have.

That is correct. It still sets a precedent of false expectations. First of all, aside from geeks who read the source code, the majority of users will assume that 'change' is returned to the same address. In fact, most users will not understand the distinction between addresses and wallets, particularly because the client does not present the pool of addresses or the balances per address. As soon as a user learns "phew! I can just restore from backup", they will similarly assume they can ALWAYS restore from the same backup.

In fact, that is precisely what should be DESIRED. I should be able to store a physical offline backup of my addresses in a sealed container at the bottom of the ocean. I should be able to give a sealed copy of the keys to my lawyer to be opened by my next of kin upon my death, which I hope will be a hundred years from now.

Let's not focus entirely on anonymity and encryption, while making it very difficult to hold on to our money. A cycle of 100 static RECYCLED keys is probably good enough for most casual users. Let the paranoid pre-generate a billion keys, but then keep it STATIC until the end of time. Or just use one address per wallet and let the paranoid launder their money using a predictable process.

It's only transactions going out that use new addresses though, right?  If transactions coming in are to the same address, then you don't have to worry, because it will only create one new address.

Therefore, you could create two wallets.  One is your day-to-day wallet that is always on your computer.  Another is created for the sole purpose of being a vault.  This second wallet is the one you give to your lawyer, and the one you put in a sealed container at the bottom of the ocean.  Any time you have an excess of funds, you can simply transfer them to this secondary wallet.

And your computer will still have your current wallet installed/running anyway, which hopefully, you've given password access to said computer to your lawyer to hand off to your next of kin in the event of your departure from this world.  So your next of kin should have access to both of your wallets, even while one is heavily protected and in storage for 100 years.

[presha]

dont worry, its only ~78 000 dollars.








...