on the new brainwallet tab, i updated my local copy to say input type="password". perhaps you could think about this for the next revision.
people probably aren't using this in public, but might still feel better not having their phrase shown on the screen.
Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 35. (Read 153019 times)
August 02, 2012, 08:08:59 PM
August 02, 2012, 12:23:52 PM
Is it possible to include the ability to encrypt and decrypt the private key string and private key QR code with a simple passphrase.
I would like to print up a paper wallet but require entering a pass phrase to decode it.. then I can leave the paper wallet on a desk and be pretty confident if someone took it they wouldn't be able to use it without some brute force cracking.
I would like to print up a paper wallet but require entering a pass phrase to decode it.. then I can leave the paper wallet on a desk and be pretty confident if someone took it they wouldn't be able to use it without some brute force cracking.
I am thinking of proposing specs for this, and then modifying my Casascius Bitcoin Utility to be a proof of concept.
What I have in mind... You all know that 5xxxxx is a private key... I am thinking of defining another prefix (e.g. Pxxxxxx) to be a "private key that needs something else to be redeemed". (In minikeys, Sxxxxx is a private key, and Pxxxxxx could be a protected minikey)
That "something else" could be a passphrase, another private key, or a combination of both. The specification I draft will accommodate base cases.
My utility will be needed to actually decrypt them, but by publishing and standardizing the encoding, I'll be able to get others to jump on the bandwagon (similar to how I did with the minikey).
August 02, 2012, 12:00:25 PM
I would like to print up a paper wallet but require entering a pass phrase to decode it.. then I can leave the paper wallet on a desk and be pretty confident if someone took it they wouldn't be able to use it without some brute force cracking.
That topic occurs earlier in this thread, but is not being implemented on BitAddress.org:
- https://bitcointalksearch.org/topic/m.750838
And it was suggested by about a half dozen people on the bitcoin banknote thread:
- https://bitcointalksearch.org/topic/m.1036869
August 02, 2012, 03:13:00 AM
Is it possible to include the ability to encrypt and decrypt the private key string and private key QR code with a simple passphrase.
I would like to print up a paper wallet but require entering a pass phrase to decode it.. then I can leave the paper wallet on a desk and be pretty confident if someone took it they wouldn't be able to use it without some brute force cracking.
I would like to print up a paper wallet but require entering a pass phrase to decode it.. then I can leave the paper wallet on a desk and be pretty confident if someone took it they wouldn't be able to use it without some brute force cracking.
July 30, 2012, 09:05:04 PM
Rescan is a command-line function, and their command line parser is already well-suited to grabbing and passing numeric arguments, so combining it with the actual rescan argument to me makes the most sense.
Makes sense to me. Something like defaults to scan from block 0, but you can give it a block # to scan from or negative number meaning from current block. eg. -10 scan last 10 blocks. And import privkey doesn't need to rescan as you can just issue the rescan command after importing a whole batch of keys. July 30, 2012, 08:39:41 PM
Both excellent ideas. Except I use the Ubuntu PPA and don't compile my own source. Drats.
We should petition for a new API call for this. Something like "setrescanstart" which can be default 0 or set off (-1) or given a block # to rescan from, just for the current session. That would save a lot of people time.
We should petition for a new API call for this. Something like "setrescanstart" which can be default 0 or set off (-1) or given a block # to rescan from, just for the current session. That would save a lot of people time.
Rescan is a command-line function, and their command line parser is already well-suited to grabbing and passing numeric arguments, so combining it with the actual rescan argument to me makes the most sense.
Actually, ongoing, a rescan shouldn't be necessary to import a private key with its balance, and ideally the client will maintain an index allowing for instant lookup of value behind a bitcoin address. Even though the developers haven't considered such an index a priority feature, there is some discussion about maintaining a meta-tree to break the barrier of not having to carry a full block chain, and that meta-tree would serve the same purpose as the index and make a block chain rescan unnecessary.
July 30, 2012, 08:03:49 PM
I just comment out these two lines in src/rpcdump.cpp:
Then you can import keys really quickly. Since you've probably just generated the private keys anyway using bitaddress.org it's a real waste of time to scan the blockchain for transactions to and from the keys. I need to restart bitcoin-qt after importing a batch of keys for the keys to show up in the 'receive coins' tab, but that's much better than having to wait for a full rescan after each importprivkey.
Code:
pwalletMain->ScanForWalletTransactions(pindexGenesisBlock, true);
pwalletMain->ReacceptWalletTransactions();
pwalletMain->ReacceptWalletTransactions();
Then you can import keys really quickly. Since you've probably just generated the private keys anyway using bitaddress.org it's a real waste of time to scan the blockchain for transactions to and from the keys. I need to restart bitcoin-qt after importing a batch of keys for the keys to show up in the 'receive coins' tab, but that's much better than having to wait for a full rescan after each importprivkey.
I did this too, and also modified the -rescan code so that -rescan=170000 (for example) only scans from block 170000 and beyond. Perfect if you know you're importing recently-received funds. IIRC, the way I did it was to modify ScanForWalletTransactions() to have one more 64-bit-integer parameter to say how many blocks to skip, and then created an overload so calls lacking the skip number will default to 0.
This way I can import lots of private keys, but only wait for a blockchain rescan once, and only from the starting point where I began receiving payments with those keys.
We should petition for a new API call for this. Something like "setrescanstart" which can be default 0 or set off (-1) or given a block # to rescan from, just for the current session. That would save a lot of people time.
July 30, 2012, 06:38:55 PM
So it's JavaScript it means it is client side computing no private key is transmitted over the internet?
That is correct. Run it offline as a further assurance.
It's a single file too - all the graphics, css, scripting are part of the main HTML file. So just save the page to a USB stick and take it to an offline machine to generate your offline keys & brain wallets.
July 30, 2012, 06:35:12 PM
So it's JavaScript it means it is client side computing no private key is transmitted over the internet?
That is correct. Run it offline as a further assurance.
Run it offline, from a liveOS (e.g., boot to an Ubuntu distribution image) for even further assurance.
Brian Krebs gives an example of doing this for online banking here:
- http://krebsonsecurity.com/2012/07/banking-on-a-live-cd/
July 30, 2012, 06:03:10 PM
So it's JavaScript it means it is client side computing no private key is transmitted over the internet?
That is correct. Run it offline as a further assurance.
July 30, 2012, 05:19:08 PM
So it's JavaScript it means it is client side computing no private key is transmitted over the internet?
July 30, 2012, 05:05:43 PM
I just comment out these two lines in src/rpcdump.cpp:
Then you can import keys really quickly. Since you've probably just generated the private keys anyway using bitaddress.org it's a real waste of time to scan the blockchain for transactions to and from the keys. I need to restart bitcoin-qt after importing a batch of keys for the keys to show up in the 'receive coins' tab, but that's much better than having to wait for a full rescan after each importprivkey.
Code:
pwalletMain->ScanForWalletTransactions(pindexGenesisBlock, true);
pwalletMain->ReacceptWalletTransactions();
Then you can import keys really quickly. Since you've probably just generated the private keys anyway using bitaddress.org it's a real waste of time to scan the blockchain for transactions to and from the keys. I need to restart bitcoin-qt after importing a batch of keys for the keys to show up in the 'receive coins' tab, but that's much better than having to wait for a full rescan after each importprivkey.
I did this too, and also modified the -rescan code so that -rescan=170000 (for example) only scans from block 170000 and beyond. Perfect if you know you're importing recently-received funds. IIRC, the way I did it was to modify ScanForWalletTransactions() to have one more 64-bit-integer parameter to say how many blocks to skip, and then created an overload so calls lacking the skip number will default to 0.
This way I can import lots of private keys, but only wait for a blockchain rescan once, and only from the starting point where I began receiving payments with those keys.
July 30, 2012, 03:18:53 PM
I tested that you cannot import a private key without knowing the walletpassphrase.
The client needs to know the passphrase in order to encrypt the private keys - that's why you can't add a private key if the wallet is locked.
It's too bad there isn't an option to tell it not to check the blockchain. For newly created keys that's not needed and it takes so much time.
I just comment out these two lines in src/rpcdump.cpp:
Code:
pwalletMain->ScanForWalletTransactions(pindexGenesisBlock, true);
pwalletMain->ReacceptWalletTransactions();
Then you can import keys really quickly. Since you've probably just generated the private keys anyway using bitaddress.org it's a real waste of time to scan the blockchain for transactions to and from the keys. I need to restart bitcoin-qt after importing a batch of keys for the keys to show up in the 'receive coins' tab, but that's much better than having to wait for a full rescan after each importprivkey.
July 29, 2012, 10:33:18 PM
Ah, you're right. I must have done that long ago as I'd totally forgotten about it.
The rpcpassword is not the same as the encryption one - walletpassphrase.
I tested that you cannot import a private key without knowing the walletpassphrase.
Which is good as otherwise someone with local system access could import hundreds of keys they already own and stand a good chance of later being able to access funds as the client uses them.
It's too bad there isn't an option to tell it not to check the blockchain. For newly created keys that's not needed and it takes so much time.
The rpcpassword is not the same as the encryption one - walletpassphrase.
I tested that you cannot import a private key without knowing the walletpassphrase.
Which is good as otherwise someone with local system access could import hundreds of keys they already own and stand a good chance of later being able to access funds as the client uses them.
It's too bad there isn't an option to tell it not to check the blockchain. For newly created keys that's not needed and it takes so much time.
July 29, 2012, 09:55:08 PM
Are you sure that method works? I was under the impression that the rpc password was different than the password used to encrypt keys.
No file editing.
No file editing.
My method is the same as yours. The only file editing needed is to set up bitcoin.conf. You can't use bitcoind to talk to a bitcoin server unless you specify the username and password. You can do that on the command line if you like, but it's more convenient to put them into bitcoin.conf once and forget about them.
You will have done that once a long time ago and probably forgot about it already, but a new user who didn't use bitcoind before will need to do it before your scripts will work:
Code:
$ bitcoind getblockcount
191445
$ mv ~/.bitcoin/bitcoin.conf x
$ bitcoind getblockcount
error: You must set rpcpassword=in the configuration file:
/home/chris/.bitcoin/bitcoin.conf
If the file does not exist, create it with owner-readable-only file permissions.
$ mv x ~/.bitcoin/bitcoin.conf
$ bitcoind getblockcount
191445
$
July 29, 2012, 07:09:43 PM
There's no easier way in the satoshi client at the moment. I don't know if there are plans to make importing private keys available from the GUI.
Are you sure that method works? I was under the impression that the rpc password was different than the password used to encrypt keys.I haven't tried that way but if I recall I did it like this, with satoshi client,
bitcoind --daemon
bitcoind walletpassphrase
bitcoind importprivkey 5blahblahblah...
bitcoind stop
No file editing. At the import step it took some long time to come back as it scans the chain. This can easily be put in a script file with pwd and key args. eg.
Code:
#!/bin/bash
bitcoind --daemon
sleep 60
bitcoind walletpassphrase $1 60
bitcoind importprivkey $2 $3
bitcoind stop
Save to file "importkey", chmod +x importkey.
Now you have a one step way to do it.
importkey
But be aware that your pwd is in the cmdline and will be in history file etc. Which is bad. With very small change it could be prompted for instead.
Revised version:
Code:
#!/bin/bash
bitcoind --daemon
echo -n "Enter passphrase:"
read -s pwd
echo "Waiting while server busy"
sleep 60
echo "Unlocking wallet"
bitcoind walletpassphrase $pwd 60
echo "Importing and scanning the chain"
bitcoind importprivkey $1 $2
echo "Done"
bitcoind stop
importkey
Note: the gui client cannot be running at same time.
Now we have a one step import. Easy to modify further into a bulk import too.
I leave as an exercise how you might do it with Windows.
Re: v1.6 Brain Wallet
That's awesome! Just tried it. Imported key with script above. Works.
July 29, 2012, 05:24:24 PM
v1.6
https://www.bitaddress.org/bitaddress.org-v1.6-SHA1-162d1ff4fd1e09222cbaca6c282672ee6c195e1b.html
https://www.bitaddress.org/bitaddress.org-v1.6-SHA1-162d1ff4fd1e09222cbaca6c282672ee6c195e1b.html
I can verify that the site has been updated and returns the same HTML from the latest commit (4dc7cc64aca58bcf9ee25a859feb9f877623faa8) in github.
To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:
$ wget --quiet -O - http://bitaddress.org|sha1sum
162d1ff4fd1e09222cbaca6c282672ee6c195e1b -
Then from my bitaddress.org repo:
$ git rev-list --max-count=1 HEAD
4dc7cc64aca58bcf9ee25a859feb9f877623faa8
$ sha1sum bitaddress.org.html
162d1ff4fd1e09222cbaca6c282672ee6c195e1b bitaddress.org.html
July 29, 2012, 04:05:57 PM
v1.6
https://www.bitaddress.org/bitaddress.org-v1.6-SHA1-162d1ff4fd1e09222cbaca6c282672ee6c195e1b.html
- Added Brain Wallet Tab. Algorithm is SHA256(passphrase).
Minimum passphrase length is 15 characters.
https://www.bitaddress.org/bitaddress.org-v1.6-SHA1-162d1ff4fd1e09222cbaca6c282672ee6c195e1b.html
- Added Brain Wallet Tab. Algorithm is SHA256(passphrase).
Minimum passphrase length is 15 characters.
July 16, 2012, 02:56:49 AM
Lmfao!
Are you serious ?
No easier way? no way with armory ?
There's no easier way in the satoshi client at the moment. I don't know if there are plans to make importing private keys available from the GUI.
Maybe Armory can do it, I've almost no experience of Armory.
July 16, 2012, 02:54:45 AM
2. run: bitcoind importprivkey 5Je4KHK15KobUcbj29xATN6z6QgZVxL4rYnBD2kaTzncS6oKmqL (replace 5J... with the private key given to you by bitaddress)
do you need to type your username and password with every command? if so, what syntax is it?
i've only ever done this through JSON, not actually on the command line.
You don't have to type it at all once you have put it into the bitcoin.conf file. The server will read that file when it starts up, and the client will read it each time you run it (assuming they both run on the same box). The server will refuse to start if the password isn't set.
Jump to: