Majority Protected Wallet Storage

[TierNolan]

A wallet.dat file could be split over multiple USB keys, such that as long as you have more than half of them, you can recover the file.

For long term storage, you could have USB at different locations.  

This isn't just for theft, data loss could occur due to damage to the files.  Assuming nobody else gets access to more  than half of them, the file is safe.

If you had 3 USB sticks you would store

USB 1
File 1: A
File 2: B

USB 2
File 1: A^W
File 2: C

USB 3
File 1: B^W
File 2: C^W

^ = XOR

W = wallet.dat file
A, B, C are random files of the same length

If you have any 2 USB sticks, you can regenerate the wallet.dat file.

This can be generalised to any number of locations.

USB 1 + 2: (A)^(A^W) = W
USB 2 + 3: (C)^(C^W) = W
USB 1 + 3: (B)^(B^W) = W

[1713862200]

1713862200

[1713862200]

1713862200

[AntiVigilante]

This is so good it put a price on your head from the banksters.

Lol I had similar notion just the other day using the symlink metaphor.

Go go go.

[JoelKatz]

While this would work, it's not a particularly good algorithm to use. The problem is if you want to store it in 13 places such that any 3 are needed, figuring out what you need to store in all 13 places gets really ugly. There are a number of algorithms that allow you to easily pick any N and any M, divide something into N pieces such that any M work, where the pieces are no larger than the original input. Excellent algorithms for this purpose are Shamir's secret sharing and Vandermonde matrices.

[X68N]

Nice idea,
but where can i download this A^W-Programm ? ;-)

[zellfaze]

Nice idea,
but where can i download this A^W-Programm ? ;-)

You can't.  This was all just in theory.  Someone would need to implement it and as JoelKatz pointed out, it could probably be done better too.

[ben-abuya]

While this would work, it's not a particularly good algorithm to use. The problem is if you want to store it in 13 places such that any 3 are needed, figuring out what you need to store in all 13 places gets really ugly. There are a number of algorithms that allow you to easily pick any N and any M, divide something into N pieces such that any M work, where the pieces are no larger than the original input. Excellent algorithms for this purpose are Shamir's secret sharing and Vandermonde matrices.

For Shamir's secret sharing there's ssss. Is there a good implementation of Vandermonde matrices?

[SgtSpike]

How about....

An application for P2P storage of all wallet files, such that you set yours for upload, and it is automatically downloaded by all other P2P users.  Of course, wallet files would be truecrypted.

Unless a way is found to break truecrypt encryption, then the wallets are very safe from accidental destruction, and very secure from those that would do harm with backups.

[TierNolan]

Unless a way is found to break truecrypt encryption, then the wallets are very safe from accidental destruction, and very secure from those that would do harm with backups.

It is possible to add data directly to the block chain.  You send a coin to yourself and encode info in the script.

The new problem becomes forgetting your password, rather than losing your wallet .

[SgtSpike]

Unless a way is found to break truecrypt encryption, then the wallets are very safe from accidental destruction, and very secure from those that would do harm with backups.

It is possible to add data directly to the block chain.  You send a coin to yourself and encode info in the script.

The new problem becomes forgetting your password, rather than losing your wallet .

In my opinion, that is a better problem to have. 

[Dirt Rider]

How about....

An application for P2P storage of all wallet files, such that you set yours for upload, and it is automatically downloaded by all other P2P users.  Of course, wallet files would be truecrypted.

Unless a way is found to break truecrypt encryption, then the wallets are very safe from accidental destruction, and very secure from those that would do harm with backups.

I like this idea! 

Only part that makes me nervous is "Unless a way is found to break truecrypt encryption...".  If a way is found, POOF!!  All coins are lost.  Or, maybe if the wallet is broken into many chunks and the p2p network had no knowledge of which chunks go together but the client would be able to figure that out based on passwords/key files/etc and some algorythm, and then retrieve the needed chunks from the network in order to rebuild the wallet?  Or something along these lines.  Interesting!!

[SgtSpike]

How about....

An application for P2P storage of all wallet files, such that you set yours for upload, and it is automatically downloaded by all other P2P users.  Of course, wallet files would be truecrypted.

Unless a way is found to break truecrypt encryption, then the wallets are very safe from accidental destruction, and very secure from those that would do harm with backups.

I like this idea! 

Only part that makes me nervous is "Unless a way is found to break truecrypt encryption...".  If a way is found, POOF!!  All coins are lost.  Or, maybe if the wallet is broken into many chunks and the p2p network had no knowledge of which chunks go together but the client would be able to figure that out based on passwords/key files/etc and some algorythm, and then retrieve the needed chunks from the network in order to rebuild the wallet?  Or something along these lines.  Interesting!!

Yeah, I would have no idea how to actually go about coding something to support an "everyone's wallet" P2P storage system, but I think it's a good idea.  The risk of 2048 bit encryption being cracked is relatively slim.  Even if it was cracked, the perp would only have access to one wallet, since each wallet was encrypted separately.  And you'd probably hear about it before too many more wallets were cracked, giving you plenty of time to create a new local wallet and transfer all your coins to it (and then create the obligatory "I've been hacked, please donate!" thread just for kicks).

One potential problem is that of bruteforcing the password, but with sufficient length, it would be impractical for an attacker to go after yours.  Just make sure it will outpace that computing law (that states a doubling of power every 18 months) for your lifetime, and you should be fine.

[o_dima]

How about....

An application for P2P storage of all wallet files, such that you set yours for upload, and it is automatically downloaded by all other P2P users.  Of course, wallet files would be truecrypted.

Unless a way is found to break truecrypt encryption, then the wallets are very safe from accidental destruction, and very secure from those that would do harm with backups.

You are talking about p2p encrypted backup system Wuala! (128 bit AES and 2048 bit RSA and SHA-256 and bla bla bla) - go and get it. It even more secure as nobody will guess that your wallet is stored in clouds with all other encrypted gargbage of the world.
 

[SgtSpike]

I see nothing in Wuala! about P2P... please enlighten me.

[o_dima]

Yes, sory it centralised... I just read this:   "You start with 1 GB... If you want more, you can either buy more storage, or trade some space on your hard disk for additional online storage."  and get it as P2P principle.

[SgtSpike]

Yes, sory it centralised... I just read this:   "You start with 1 GB... If you want more, you can either buy more storage, or trade some space on your hard disk for additional online storage."  and get it as P2P principle.

Ahhh, gotcha.  Pretty neat idea then.  But it's still centralized, which means it MAY not last forever.  The nice thing about a truly decentralized P2P storage system is that it would never die, as long as people kept using it.

[TierNolan]

I created a c program that will do the shamir sharing system.

This system generates shares that are the same size as the original secret file.

The secret must be a number from 0 to 65808 (uses 65809 as prime for modulo arithmetic).

However, you can use it over and over again on a file.  Keeping the numbers small means that a big number library isn't needed and it doesn't weaken the scheme.  You still need (file size)*(number of shares) worth of random data.

In fact, there is an implementation which does it one byte at a time.

By using 65809 as the prime, it will be able to encode one byte and 2 byte secrets (65536 + 256) = 65792. 

The next step is to add a file reader and have it generate n secret shares.

[SgtSpike]

Why do you need to generate a bunch of useless data to obscure the original wallet file if the original wallet file is encrypted?

[TierNolan]

Why do you need to generate a bunch of useless data to obscure the original wallet file if the original wallet file is encrypted?

This means that you don't need to remember a password.  If you create 5 shares, then you can recover your file directly, as long as you have at least 3 of them.  In fact, the system allows as many shares as you want and any threshold.  You could have 100 shares and only need 2 to decode the file.

In fact, it would be worth doing both.  You could encrypt your wallet.dat file and use this system as a backup.

[SgtSpike]

Why do you need to generate a bunch of useless data to obscure the original wallet file if the original wallet file is encrypted?

This means that you don't need to remember a password.  If you create 5 shares, then you can recover your file directly, as long as you have at least 3 of them.  In fact, the system allows as many shares as you want and any threshold.  You could have 100 shares and only need 2 to decode the file.

In fact, it would be worth doing both.  You could encrypt your wallet.dat file and use this system as a backup.

Couldn't someone just download all 65000 random files to find the one that is an actual wallet file?

I guess I am really confused about how this would work.  If I needed shares to recreate the original file, why wouldn't I just keep the original file to begin with?  What happens if I lose my shares?  The file is gone?  Wouldn't that defeat the purpose of the backup to begin with?

[TierNolan]

I guess I am really confused about how this would work.  If I needed shares to recreate the original file, why wouldn't I just keep the original file to begin with?  What happens if I lose my shares?  The file is gone?  Wouldn't that defeat the purpose of the backup to begin with?

The process is

encode file

This generates 5 files
file.1
file.2
file.3
file.4
file.5

you can now delete the original file

You put the shares on 5 different USB drives and spread them out.

If you need to get the file back, you need any 3 of the 5 shares.

decode file.2 file.3 file.5

This generates the original file.

This means that if 1 share gets stolen, you can still recover the original file.

In fact, if any of the 5 are lost/stolen/broken, it is probably worth regenerating all 5.

The way I think it would work is that you would be prompted to insert the USB sticks one at a time.