Topic: . - page 4. (Read 64536 times)

me, for one. Be happy that your bitcoins will be more valuable when I lose mine.

Ok sorry. How exactly.. am I installing bitcoin to the flashdrive

Now that I think about it, I don't see how it could be implemented with just cryptography. But with Bitcoin, it's easy. Just use future transactions, which will be entered immediately into the block chain, but won't actually take effect until a given block number. You do a transaction that empties out your private account into the joint account, in a block that will be computed 30 days from now. Then, each day you're around, you just transfer your bitcoins into a new private account, and that future transaction will fail because the originating account will be empty. You also set up another future transaction to transfer money from your new private account into the shared account in another 30 days. There are probably ways to streamline this, but I don't see any theoretical difficulties.

Amazingly, it looks like this feature is already baked into Bitcoin:

http://forum.bitcoin.org/index.php?topic=8821.0

A dead man's switch, very nice. I'd be interested to hear details on how to implement this.

This is actually a very interesting question, because the two problems we want to solve are adversarial. If only one person knows the password (you), you could forget it, or something could happen to you and your money would be lost forever. If many people know the password, there's less of a chance it will get lost, but more of a chance someone else will steal the money, or get hacked. Secret sharing is cool, but it's really just a way to tweak the tradeoffs.

Here's another idea, a time lock. You could decide that for a period of 30 days, nobody has access but you. But if for some reason, you're unable to access the encryption for 30 days, either because you're injured, kidnapped, or forgot the password, then the shared secret password would go into effect and the second group would be able to access the funds. Of course there are all kinds of ways to game this, but it's an old stand by in meatspace security, and it should be a useful tool for the paranoid.

splitting the key - http://en.wikipedia.org/wiki/Secret_sharing
might be one way to spread that risk, or start a tontine,
if you're that worried about amnesia.

Eh, maybe if you're not used to using GNUPG. If I lose my key and password I'll have bigger problems than my bitcoin wallet.

I just want to point out that in many cases, the risk of losing the passwords/private keys, or screwing up one of the many steps, is orders of magnitude greater than some smart bitcoin trojan keylogger being on your linux box. Losing the password is a very real risk.

Oooh, I was thinking of trying to do something like this by violently hacking it out of the client code. I'll have a look at this instead, thanks!

Since you are willing to assume (modest) advances in software by the time you want to withdraw savings, I suggest:

1. Get a trustworthy live CD system with VAPORWARE A [1] that creates a Bitcoin key pair and displays its Bitcoin address without having to download the block chain.
1a. Alternatively, the system just needs an "openssl" program that supports "openssl ecparam -name secp256k1 -genkey" and "openssl ec -pubout", and you can do some base-58 math to get the address.
1b. Alternatively, for better security, learn to do cryptography on a pocket calculator, an abacus, by writing numbers in sand, or in your head, and dispense with computers in what follows.  

2. Boot a trustworthy machine from the CD in a secure, non-networked location, and run Vaporware A to generate a key pair in PEM format (or a more compact form such as Sipa's).
2a. For added security, use a system without any writable media.

3. (Optional: requires remembering a pass phrase) encrypt the key pair with "gpg -c" or similar.

4. Copy the key pair and address from your terminal to a piece of paper.  You'd better generate and copy a checksum of the key pair to make sure you get it right later.
4a. Alternatively, if you trust your printer, attach it and print out the key pair.
4b. Alternatively, you could print it as a QR code, if your vaporware supports this.

5. Shut down the live CD machine.

6. Send your BTC to the new address.  Use some vaporware (a trusted block explorer) to make sure it arrives.

7. Go about your business until you want to spend the BTC.

8. Using Block Explorer or a similar tool, find the transaction out-point (transaction hash + output number) of each coin you want to spend.

9. Use VAPORWARE B to create a file containing the parts of the block chain needed to verify those transactions to your address.  (This could be the entire chain or just the block headers, Merkle tree stubs, and the transactions in question as described in Satoshi's paper.)

10. Copy the verification data to media such as a thumb drive.
10a. Alternatively, for a little extra security, prepare for several long nights of typing it in (assuming it is just the headers and Merkle stubs).

11. Boot a trustworthy live CD with VAPORWARE C on your secure, non-networked machine.

12. Using the verification data and out-points as input, run Vaporware C to sign a transaction.  This program will prompt for the key pair you generated in Step 2, as well as an amount and recipient address.
12a. If you worry about anonymity, you will have another secure key pair ready to receive the change.

13. Vaporware C displays a graph of network hash rate (or difficulty) over time.  Make sure it looks about right and there are no big, unfamiliar dips.  Cf. http://bitcoin.sipa.be/speed-ever.png.  This helps Vaporware C trust that the outputs obtained in Step 8 are in the amounts you think they are, so you do not accidentally give some lucky miner a huge transaction fee.
13a. If you don't care about this possibility, you don't need Vaporware B or the verification data from Steps 9-10.
13b. [Edit] I think, actually, the raw transactions and their hashes would suffice.

14. Copy the transaction signature to the thumb drive, paper, or similar.

15. Shut down the secure system.

16. Using VAPORWARE D on a regular, networked system, enter and upload the signed transaction to spend the coins.

17. Wait for the network to confirm the transaction.

18. Relax!

Note, you would want to test these procedures a few dozen times before entrusting your savings to them.

[1] Vaporware A, early alpha version: https://github.com/jtobey/bitcoin/raw/importkey/contrib/genkey.py

I think you are a referring to the common reminder that a backup of wallet.dat needs to be refreshed regularly because the backup contains a limited number of "future keys" as configured by the keypool.  That is true, but the client only uses up one of those keys when you manually create a new address or when you send money to someone else.  Since in this case, you've created a special wallet.dat for the purposes of only ever having 1 address and generally only receiving money, the backup doesn't need to be refreshed often as keys will not get used up.  Now, if you start to "withdrawl" money from your "savings account", you'll start using keys from the keypool and you should start re-backing up the wallet.

Nope, all the transactions are going to the same key.


Well the backup has nothing to do with it. The flash drive is only to transfer the encrypted wallet to somewhere you can safely store backups, and to transfer the address so you can copy/paste it instead of trying to retype it and maybe sending thousands of BTC to the wrong address.


No.

Just to make sure.. from my knowledge.... This would work but you would have to update the client before you hit 1 hundred transactions because of your keypool right?

So assuming thats true. If I update the flashdrive every few transactions, If i leave alone the back up it would still be behind right?

If say i send 100 transactions to the backup wallet, then open my flashdrive and update. then I send another transaction to it and open the older back up stored somewhere else, id be missing the last transaction right?

Actually to me the most important step is generating the addresses after the machine is disconnected from the net, but yeah if you're going to reconnect it later, shred the file.

Wow thanks, I had totally overlooked this essential step.

No, this is far too complex and misses a key step to be really secure.

1. Install bitcoin on a computer.
2. Disconnect computer from the internet
3. Start bitcoin and generate a new address. This will be your savings address.
4. copy and paste the savings address to a text file
5. Dump the wallet from bitcoin, gpg encrypt or put on a truecrypt volume
6. copy the address-in-text-file and encrypted wallet to another computer, dropbox, s3, send to friends, etc.
7. shred (using a file shredder, like 'shred' in linux) the original wallet.dat file
8. Now save by sending coins always to that savings address.

Note, when you want to access your coins this will introduce some risk. To do this even better generate a set of new addresses and distribute between them. Then when retrieving coins you only risk a subset at a time.

Yeah, the folder will grow in size as you download new blocks and create new addresses. I don't really see an advantage in having the whole folder inside the encrypted volume so I just put the wallet.dat file and symlink to it. Makes for easier backup.

Btw, anyone knows by how much does wallet.dat grow with every new address past the default pool of 100?

Okay,
I am a total noob to this. I am running a Mac and through the wiki, some guy explained that putting my wallet on an encrypted disk image would be fine. 

The other issue was that he recommended putting the whole bitcoin folder in the image.... Is that overkill?
Does that folder (which resides in the Library/Application Support) get larger over time?

Thanks for all the helpful advice!

Ok i just read up on the wallet.dat file So that is fairly simple.

Now obviously some server out there is making all these transactions right? So when I send money to my backup wallet some server is going to try to amke that happen for a long time. Makes me wonder how it is funded.

Yes and yes.