Generate address through shell using /dev/random?

[Tacticat]

If I'm not mistaken, a private key is just a 256 bit number.

Any way I can generate it on my own, without any special application by running a command that fetches it through /dev/random (or /dev/urandom) and outputs it so that I can import it later on any client?

Thanks!

[flatfly]

Sure:

Code:

od -An -N32 -x /dev/urandom

I think both Armory and Electrum should happily import this format (without the spaces)

[Blazr]

Sure:

Code:

od -An -N32 -x /dev/urandom

I think both Armory and Electrum should happily import this format (without the spaces)

WHAT? Its that easy? Why don't people just do this when generating paper wallets etc rather than using tools like bitaddress.org.

[flatfly]

Sure:

Code:

od -An -N32 -x /dev/urandom

I think both Armory and Electrum should happily import this format (without the spaces)

WHAT? Its that easy? Why don't people just do this when generating paper wallets etc rather than using tools like bitaddress.org.

Very good question... By the way, there was an error in my original line - fixed now (N32, not N16).

[pc]

It uses more than just /dev/random, but I wrote a shell script for myself that basically just uses OpenSSL to generate the key.

The tricky part (to the extent that there is one) isn't generating the private key so much as calculating the corresponding address so that you can receive funds to it.

But you can just generate the random number to use as a key, and then use bitaddress.org's "Wallet Details" tab to calculate the address or convert the private key into the format used by your bitcoin client for when you want to spend them.

[Tacticat]

Sure:

Code:

od -An -N32 -x /dev/urandom

I think both Armory and Electrum should happily import this format (without the spaces)

Sorry that I ask,
But shouldn't it be a 256 bit number? (I assume that the output is in hexadecimal).

[flatfly]

Sure:

Code:

od -An -N32 -x /dev/urandom

I think both Armory and Electrum should happily import this format (without the spaces)

Sorry that I ask,
But shouldn't it be a 256 bit number? (I assume that the output is in hexadecimal).

Well it does produce a 256-bit number:
-N32 = 32 bytes = 64 hex digits = 256 bits.

I just tested importing it successfully in Armory.

[DannyHamilton]

Sure:

Code:

od -An -N32 -x /dev/urandom

I think both Armory and Electrum should happily import this format (without the spaces)

WHAT? Its that easy? Why don't people just do this when generating paper wallets etc rather than using tools like bitaddress.org.

Yep. It's that easy.

This is why "brainwallets" work too. The following should generate a 256 bit "private key" for you.  Of course, if anyone else ever generates a private key using the same passphrase as you (intentionally or accidentally), they will be able to take/spend all bitcoins associated with the private key.

echo -n "Your brain wallet passphrase here" |shasum -a 256

[BkkCoins]

This works too - all on one line,

hexdump -v -e '/1 "%02X"' -n 32 /dev/urandom

033A39517EA0D235D6E8C54619C915002E3BEE821B68EE100E73D6281CA67801

[BkkCoins]

I created a hex to wif format conversion util and just updated it to take input from stdin, one key per line.
Now updated to be more useful - takes hex or wif private keys in and outputs related data according to a given format .

Here:
https://github.com/bkkcoins/misc/tree/master/keyfmt

So you can do this,

hexdump -v -e '/1 "%02X"' -n 32 /dev/urandom | keyfmt %w
5JZ4KXMXgewXTAjqYYaqvczXV7NuKKQibi15yGY6i6DXmNibghG

And this,

for x in {1..3}; do hexdump -v -e '/1 "%02X"' -n 32 /dev/urandom | keyfmt %w; done
5JbWBwyvNxxTiF32LfR8bA9kpvrTftpjLEXNzrNdwpGQrFDZjYg
5K2XMRW1iLddF8RX6sXRULRMaf6d6CiRoHxjkSEdTdE7ph3XKwu
5JdXrfHxp4Z3ZnsS77uvHpFUwqKm2DAJtK2X6MNP69AucYooLeP

The format argument allows you to provide a format string and it will output various related/converted data as you specify. eg.

keyfmt "Address: %a\nPrivkey: %w"  - outputs format like vanitygen
keyfmt "%a:%w" - outputs format suitable for Electrum import.

Reads hex data from stdin and has currently these possible variables for output:

 %h = HEX privkey
 %w = WIF privkey
 %p = public key
 %a = address

eg.

Code:

hexdump -v -e '/1 "%02X"' -n 32 /dev/urandom | keyfmt 'Address: %a\nPrivkey: %w'
Address: 13nDMqrtEqMvDyE7MgFKYfF2i8mAAJtSZn
Privkey: 5JvJd7kdC8DeuNwKfAWWEFpLM54FXmwyPaoTDiFi4K5PB427AA9

It currently only takes HEX keys in but if people would find it useful I could have it take WIF keys as well. That would be a bit more of a swiss army bitcoin knife.
Now supports either Hex or WIF input keys with autodetection.

Simple python code is a good demo of how to get public key and address from private key in Python. Requires ecdsa module (sudo pip install ecdsa).

[Scrat Acorns]

Technically, not all 256 bit numbers are valid ECDSA priv keys. In the secp256k1 curve there's a very very small chance that your key won't be valid. That chance is so small that it will never happen.

Here's a way to create a private key with the openssl lib:
https://bitcointalk.org/index.php?topic=132061.msg1415456#msg1415456

Most of that code is the encoding, the key is created by a few simple openssl commands in the end.

If you're gonna use the shell, use /dev/random instead of /dev/urandom for maximum paranoid mode. It might not be instant depending on your system's stored entropy though so get ready to move your mouse around like a monkey on crack in order to generate more entropy and make it finish faster.

[Tacticat]

I created a hex to wif format conversion util and just updated it to take input from stdin, one key per line.
Now updated to be more useful - takes hex or wif private keys in and outputs related data according to a given format .

Here:
https://github.com/bkkcoins/misc/tree/master/keyfmt

So you can do this,

hexdump -v -e '/1 "%02X"' -n 32 /dev/urandom | keyfmt %w
5JZ4KXMXgewXTAjqYYaqvczXV7NuKKQibi15yGY6i6DXmNibghG

And this,

for x in {1..3}; do hexdump -v -e '/1 "%02X"' -n 32 /dev/urandom | keyfmt %w; done
5JbWBwyvNxxTiF32LfR8bA9kpvrTftpjLEXNzrNdwpGQrFDZjYg
5K2XMRW1iLddF8RX6sXRULRMaf6d6CiRoHxjkSEdTdE7ph3XKwu
5JdXrfHxp4Z3ZnsS77uvHpFUwqKm2DAJtK2X6MNP69AucYooLeP

The format argument allows you to provide a format string and it will output various related/converted data as you specify. eg.

keyfmt "Address: %a\nPrivkey: %w"  - outputs format like vanitygen
keyfmt "%a:%w" - outputs format suitable for Electrum import.

Reads hex data from stdin and has currently these possible variables for output:

 %h = HEX privkey
 %w = WIF privkey
 %p = public key
 %a = address

eg.

Code:

hexdump -v -e '/1 "%02X"' -n 32 /dev/urandom | keyfmt 'Address: %a\nPrivkey: %w'
Address: 13nDMqrtEqMvDyE7MgFKYfF2i8mAAJtSZn
Privkey: 5JvJd7kdC8DeuNwKfAWWEFpLM54FXmwyPaoTDiFi4K5PB427AA9

It currently only takes HEX keys in but if people would find it useful I could have it take WIF keys as well. That would be a bit more of a swiss army bitcoin knife.
Now supports either Hex or WIF input keys with autodetection.

Simple python code is a good demo of how to get public key and address from private key in Python. Requires ecdsa module (sudo pip install ecdsa).

Holy shit this is awesome!

This could be combined with "qrenconde" and create paper wallets ready to be printed. Is there any script or applications that will create a Pubkey from the privatekey?

[BkkCoins]

Holy shit this is awesome!

This could be combined with "qrenconde" and create paper wallets ready to be printed. Is there any script or applications that will create a Pubkey from the privatekey?

This utility can do it for you. Just use the %p variable. (see the readme)
eg.

hexdump -v -e '/1 "%02X"' -n 32 /dev/random | keyfmt %p

Will output the public key for the random data input. If you want both then use,

hexdump -v -e '/1 "%02X"' -n 32 /dev/random | keyfmt '%w\n%p'

As for qrencode - that should work. I think you could also generate an svg graphic very easily that should scale well, and include text. Or use qrencode and then img magik to write a text label on the png output.

Technically, not all 256 bit numbers are valid ECDSA priv keys. In the secp256k1 curve there's a very very small chance that your key won't be valid. That chance is so small that it will never happen.

I didn't know that. Is there a test for a valid key that can reject a bad random sequence. I know there is a zero point but I think that can be ignored for practical purposes. The chances of creating a random stream that gives the zero point must be ~0.

Agreed /dev/random is better.

[BkkCoins]

I just updated keyfmt to strip spaces on inputs. This allows using od or other spacey output directly,
eg.

od -An -N32 -xw32 /dev/random |keyfmt %a:%w

(adding w32 puts all hex data on one line)

[Scrat Acorns]

Is there a test for a valid key that can reject a bad random sequence. I know there is a zero point but I think that can be ignored for practical purposes. The chances of creating a random stream that gives the zero point must be ~0.

There's a range:
https://en.bitcoin.it/wiki/Private_key#Range_of_valid_private_keys

Still less than a 1 in 2¹²⁷ chance of missing it if I calculated this correctly.

[flatfly]

Is there a test for a valid key that can reject a bad random sequence. I know there is a zero point but I think that can be ignored for practical purposes. The chances of creating a random stream that gives the zero point must be ~0.

There's a range:
https://en.bitcoin.it/wiki/Private_key#Range_of_valid_private_keys

Still less than a 1 in 2¹²⁷ chance of missing it if I calculated this correctly.

In other words it's really not worth checking for that, unless you also check for bits flipped by cosmic rays - which is MUCH more likely to happen - see below links for a nice read

 http://lambda-diode.com/opinion/ecc-memory

 http://stackoverflow.com/questions/2580933/cosmic-rays-what-is-the-probability-they-will-affect-a-program

[Scrat Acorns]

In other words it's really not worth checking for that, unless you also check for bits flipped by cosmic rays - which is MUCH more likely to happen - see below link

 http://lambda-diode.com/opinion/ecc-memory

In fact getting hit by an asteroid is more likely to happen than creating an invalid private key with random data, even if you create millions of them during your lifetime.

[BkkCoins]

In other words it's really not worth checking for that, unless you also check for bits flipped by cosmic rays - which is MUCH more likely to happen - see below link

 http://lambda-diode.com/opinion/ecc-memory

In fact getting hit by an asteroid is more likely to happen than creating an invalid private key with random data, even if you create millions of them during your lifetime.

It turns out the value of "r" in the curve constants is the same value and is already in the code, so I could test for it easily. But the problem is what to do about it. If the input key is random there would be no real problem altering it (maybe by a mod operation?) such that it is valid and continuing. It's easy enough if this is being used during generation. But if the input was not random and was an existing key value from some other source then altering it may be the wrong action. eg. If it was used for converting database data. So I should output an error message.

If I mod the input by the value "r" then it would stay within bounds and any input that was invalid would be "fixed" in a knowable way.

I guess I'll leave it as untested for now, given how unlikely it is, but I'm open to a good argument for a better choice.