Bitcoin Forum
September 29, 2016, 05:01:00 AM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Privacy versus Safety: handling change  (Read 3044 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
July 17, 2010, 02:13:46 PM
 #1

Here's how you can lose coins by backing up and restoring your wallet file:

Lets say you have one shiny 1,000 Bitcoin coin in your wallet (it's actually just a transaction for 1,000 bitcoins paid to a public key that's stored in your wallet).

You backup that file.

Now you spend 1 Bitcoin.  Your shiny 1,000 BTC coin is broken into 1BTC, plus 999BTC in change.  That change is given a new, different public key.

Now if you restore your wallet file, Bitcoin sees that the 1,000BTC coin has been spent-- 1BTC was sent somewhere, and the other 999BTC was sent somewhere else.  Because you don't have the key for the 999BTC, it has no idea that those coins belong to you.

So they're lost.

Trying out alternative policies for handling change on the TEST network would be a good idea, in my opinion.

Maybe change transactions should always get signed with the same public key, so you wouldn't lose coins when restoring your wallet... although that would give you less privacy because it would tend to tie all your transactions together.

Maybe your wallet should get initially populated with 100 "change" addresses, with one randomly chosen as needed.  And some super-geeky way of replacing them with another, new, 100 addresses.

Maybe there's an even better way of handling the "I lost BTC when I restored my wallet" problem; ideas?

How often do you get the chance to work on a potentially world-changing project?
1475125260
Hero Member
*
Offline Offline

Posts: 1475125260

View Profile Personal Message (Offline)

Ignore
1475125260
Reply with quote  #2

1475125260
Report to moderator
1475125260
Hero Member
*
Offline Offline

Posts: 1475125260

View Profile Personal Message (Offline)

Ignore
1475125260
Reply with quote  #2

1475125260
Report to moderator
1475125260
Hero Member
*
Offline Offline

Posts: 1475125260

View Profile Personal Message (Offline)

Ignore
1475125260
Reply with quote  #2

1475125260
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1475125260
Hero Member
*
Offline Offline

Posts: 1475125260

View Profile Personal Message (Offline)

Ignore
1475125260
Reply with quote  #2

1475125260
Report to moderator
1475125260
Hero Member
*
Offline Offline

Posts: 1475125260

View Profile Personal Message (Offline)

Ignore
1475125260
Reply with quote  #2

1475125260
Report to moderator
1475125260
Hero Member
*
Offline Offline

Posts: 1475125260

View Profile Personal Message (Offline)

Ignore
1475125260
Reply with quote  #2

1475125260
Report to moderator
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
July 17, 2010, 02:25:28 PM
 #2

Isn't this just a result of restoring to an out of date backup?

That aside,

Simple possible change return methods:

a) change gets returned to the address it came from.
b) change gets returned to a newly generated bitcoin address.

Most people wont care and will expect the a) behavior, so make this the default.
Those who care about the privacy of their transactions can enable b) through some option setting in the client.
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 17, 2010, 04:27:39 PM
 #3

We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed.  They aren't very big, so it wouldn't hurt to have a lot of them.  This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it.  Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.

The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses.  When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.

There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat.  I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
July 17, 2010, 09:15:21 PM
 #4

If you can't restore a backup that is out of date at all then won't you have to backup after every transaction?

Is this a possible solution? I have two computers, I use one all the time for small transactions. I occasionally sock away a large amount to my other machine just by transfering then I also immediately backup that machine's wallet.dat to a secure place.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
dete
Newbie
*
Offline Offline

Activity: 22



View Profile
July 18, 2010, 06:22:34 AM
 #5

Surely the "coins" stored in wallet.dat are essentially just a cache, though, right?  The "real" count of BTC that I can spend are encoded into the chain.

If I still have all my private keys, I should be able to scan the block list to recover that "cache".

Suggestion: Include a block number/id in the wallet which is the last-known-good point for that wallet.  When a wallet is restored from backup, you can rescan the new blocks to be sure it's up-to-date.

Second Suggestion: All the user to rebuild a wallet without re-downloading all the keys.

Final Suggestion: Separate the "real" critical data (the private keys), from the "cache" (my current coins).  There is no reason to conflate the data that is absolutely critical for me to access my coins from a system designed to efficiently find my coins and let me spend them.

(Unless I'm fundamentally misunderstanding the inner workings of BitCoin!)

Send me a tip!
1Benh27wZoszDjvGTSWTWD2CWPr4rWUoGk
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2422


View Profile
July 18, 2010, 06:36:18 AM
 #6

dete: You are losing the private keys in the case. Almost every time you send coins, you're also sending some coins back to yourself, to a brand new keypair. Since this new private key is not in the backup, you lose the coins.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
dete
Newbie
*
Offline Offline

Activity: 22



View Profile
July 18, 2010, 07:49:02 AM
 #7

Thanks Theymos: That clears things up a lot!  (I wasn't sure who the change-handling code worked...)

Send me a tip!
1Benh27wZoszDjvGTSWTWD2CWPr4rWUoGk
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
August 11, 2010, 08:54:44 AM
 #8

Has there been any progress on this?
What do we need to do to make it happen?
A user recently lost 8999 BTC due to this problem, it would be good if we could eliminate it.
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
August 11, 2010, 06:00:48 PM
 #9

I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
Yeah, that would be useful behaviour. I think better key management - the ability to import, export, create, and delete addresses at will - is also in order. The current system only let you create them - you cannot delete them or export them to a file.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
August 11, 2010, 06:42:37 PM
 #10

Is it possible to get an address collision?

throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 12, 2010, 12:52:15 PM
 #11

We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed.  They aren't very big, so it wouldn't hurt to have a lot of them.  This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it.  Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.

The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses.  When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.

There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat.  I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.

It should be better to allow exporting of keypairs in text form, as is done with PGP, and importing them back.
It would be also useful to add more control over transaction outputs (and inputs) in, say, no-warranty-expert-mode.
I request manual selection of tx inputs and specification of tx outputs. Let it only exist in command-line mode with -do-as-i-say option.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 16, 2010, 05:02:17 PM
 #12

Is it possible to get an address collision?

Possible - yes.
Practical - not at the moment.

The easiest way to prevent effectively permanent bitcoin loss is to backup and jealously protect the  private keys which are one roughly 78 digit decimal numbers or 64 digit hexadecimal number for all your bitcoin addresses. Everything else is recoverable.

ByteCoin
silverman
Jr. Member
*
Offline Offline

Activity: 59


View Profile
August 16, 2010, 07:34:17 PM
 #13

Make the Bitcoin wallet a directory with a series of snapshots of state, each transaction saving its new state?

An optional offsite backup cache would be nice too.


Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!