mroshow / bitcoin-wallet

Automatically exported from code.google.com/p/bitcoin-wallet
1 stars 0 forks source link

Import Paper Wallets #244

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Paper wallets are a very convenient form of cold storage.
It's easy to create one using a client side software like bitaddress.org, or 
safepaperwallet.com. You can then print it, and send money to it using it 
public QR code.

However, to expend from this storage it is required a client that can either 
"withdraw" from cold storage, or import the wallet from its printed private key.

Due to the way bitcoin-wallet works, I think the easier option is to implement 
the import wallet feature. Of course in the future a minor enhancement would be 
to provide the "withdraw" button, which is a concatenation of import, send and 
delete.

Also it would be nice to implement the BIP 38 encryption, which adds a pin to 
the private key in the paper wallet, and is a nice feature that is becoming 
standard.

Original issue reported on code.google.com by Alejandr...@gmail.com on 19 Nov 2013 at 2:29

GoogleCodeExporter commented 9 years ago
Paper wallets/private key import cannot work with SPV clients, unless the 
community agrees on extensions to the P2P protocol. For this, I suggest taking 
the discussion to the Bitcoin development mailing list.

Original comment by andreas....@gmail.com on 19 Nov 2013 at 8:41

GoogleCodeExporter commented 9 years ago
Hmm, I understand the problem, however, if the paper wallet is generated 
offline, and has never been used, importing its public address would be 
identical to generating the number an then monitoring the required pattern of 
the block, am I wrong in this supposition?, of course if the wallet has never 
been used on the network.

So the use case I'm thinking of, would still be viable: Create a paper wallet, 
import its public key as an address, and use it as a saving account. When you 
want to withdraw from it, then you scan the QR of the private key, in order to 
sign the transaction.

This feature of course would have to be an expert feature, and have a warning: 
"if you ever used this paper wallet before importing it you are screwed".

What do you think?
Btw, I'm new to the bitcoin world, but I do know a bit of android, so I could 
help implementing this feature.

Original comment by Alejandr...@gmail.com on 19 Nov 2013 at 2:45

GoogleCodeExporter commented 9 years ago
Btw, other SPV clients seem to have solved this problem: 
https://multibit.org/help_importASingleKey.html.

And this particular requirement, gives a hint on how it will work out:
Add in your new key and a date a bit before when you created it.

Regards.

Original comment by Alejandr...@gmail.com on 19 Nov 2013 at 3:02

GoogleCodeExporter commented 9 years ago
You can use the same process for Bitcoin Wallet. Its risky, though. I would 
recommend encrypting the file via openssl so you don't have to transmit it 
unencrypted.

Original comment by andreas....@gmail.com on 19 Nov 2013 at 3:09

GoogleCodeExporter commented 9 years ago
If this process is valid, then importing a paper wallet also is, you would only 
need to provide an estimated date of creation (it could be a date before), or 
like I said before, import an unused wallet, and assume its creation day today.

Doing this process is not only risky, is painful, the idea of paper wallets is 
to use them as safe saving accounts until you withdraw the money, then you 
simply throw the paper and use other. They are safe because private key has 
never touched an online device, and they are convenient because you can 
generate a dozen and print them in 2 min. So this process is undermining both 
objectives: security and convenience.

I still think this enhancement is valid. Why wouln't you?

Original comment by Alejandr...@gmail.com on 19 Nov 2013 at 3:20

GoogleCodeExporter commented 9 years ago
Well its still risky to import a private key from somewhere. I do not want to 
loop through the support for that. If anything, I'd prefer sweeping a key 
rather than importing. If you implement that, I'd consider merging.

Original comment by andreas....@gmail.com on 19 Nov 2013 at 4:51

GoogleCodeExporter commented 9 years ago
Issue 260 has been merged into this issue.

Original comment by andreas....@gmail.com on 8 Dec 2013 at 9:53

GoogleCodeExporter commented 9 years ago
Issue 260 has been merged into this issue.

Original comment by andreas....@gmail.com on 8 Dec 2013 at 10:27