[GUIDE] Create a Bitcoin address from scratch

[jackjack]

As requested here: https://bitcointalk.org/index.php?topic=37966.msg466652#msg466652

• Download Pywallet. You only need to install Python 2.7. If you encounter some problems installing Python, post in pywallet thread, someone will answer you quickly
• Pick 64 random characters in the following list: [1234567890abcdef]
• For example, say you chose "1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef"
• Run the console (Windows-R then "cmd" then Enter on windows)
• Run:

Code:

cd 'the directory where you downloaded pywallet'

• Then run:

Code:

./pywallet.py --info --importhex --importprivkey 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef

This should returns:

Code:

Address (Bitcoin): 19ffB4HttNCHfY1t3YuErEytCspyHyVMwv
Privkey (Bitcoin): 5HxJb9hZNXEEk9SAM3J7gXBK6zgkkLW5dpx2WDdBZub8HxifdDH
Hexprivkey: 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef

The first line is your address
The second and the third is two different manners to write your private key, you don't have to save/print both, but be sure to keep at least one of them

[1713565603]

1713565603

[1713565603]

1713565603

[TTBit]

Just saw this thread. THANK YOU!

[TTBit]

jackjack, thank you for the guide.

I was hoping someone could help, I can't get it to work.

I am not a programmer.

* Windows 7, 64bit
* installed Python 2.7, its in \Python27
* Downloaded v1.2 from: https://github.com/jackjack-jj/pywallet I threw it right in the \Python27 directory

Code:

C:\Python27>pywallet.py
Traceback (most recent call last):
  File "C:\Python27\pywallet.py", line 1320, in <module>
    class WIRoot(resource.Resource):
NameError: name 'resource' is not defined

EDIT: Fixed. Thank you!

[davux]

At first glance, this could sound like a great way to store your money: pick an easy-to-remember, passphrase-like private key and you're done. Better yet, come up with an algorithm for hashing any ASCII string as a [1234567890abcdef]{64} string and you can literally store your money in your mind.

The problem with this approach is that your private key wouldn't be so random anymore, which reduces dangerously the number of possibilities, bringing it down to a brute-forceable set.

Taking it the other way round: if people start to generate addresses based on easy-to-remember private keys, then a group of people can start to pre-calculate the most obvious ones (the amount will depend on my computing power and how much time I spend doing it), check their balance regularly and take their coins.

This is only an impression, though – I didn't do any maths and might be totally wrong (which would be nice!). It would be interesting to check this assertion with actual numbers.

[TTBit]

I intend to come up with random, save it on paper and store it where one would store jewelry/gold. What's cool is that I can now store my 'gold' in my safety deposit box at the bank, in my wallet, engraved on my toothbrush, or on a postcard sent to my grandma. Double edged sword indeed, my 'gold' can now be stolen in many different places too.

[casascius]

Jackjack,

WOuld you be willing to update pywallet to support the import of the 22-character private keys I will be using on my physical bitcoins?  I would like to encourage this (or a similar format) for other applications... 22 characters fits well on a small QR code without being ridiculously dense, yet still provides a decent amount of entropy (around 128 bits).

My codes are 22 characters, and the private key is simply the sha256 of the 22 characters as a string, with the following constraints:

1. the first character is always 'S'
2. all the characters come from the base58 alphabet
3. as a guard against typos, all my codes conform to the following rule: the sha256 of (string + "?") will be a hash that begins with eight zero bits (so, first byte is 00 hex).  That is, the string with a question mark appended, so 23 characters.
4. they are printed in the coins in four groups - five,six,six,five characters so they fit on a circle.  There are no separators or spaces between the groups for the purpose of the hash calculation, but the user might enter them anyway.  Respond gracefully.

[casascius]

At first glance, this could sound like a great way to store your money: pick an easy-to-remember, passphrase-like private key and you're done. Better yet, come up with an algorithm for hashing any ASCII string as a [1234567890abcdef]{64} string and you can literally store your money in your mind.

One such algorithm exists... it's known as SHA256 and is used widely within Bitcoin =).  Download Casascius Bitcoin Utility and you can see passphrases converted directly to Bitcoin addresses.

The problem with this approach is that your private key wouldn't be so random anymore, which reduces dangerously the number of possibilities, bringing it down to a brute-forceable set.

Only if people chose dumb passphrases.  Anything strong will take an impossible amount of time to brute force.  Brute forcing ECDSA keys is also incredibly slow (CPU intensive), much slower than brute forcing hashes by several orders of magnitude.

[jackjack]

At first glance, this could sound like a great way to store your money: pick an easy-to-remember, passphrase-like private key and you're done. Better yet, come up with an algorithm for hashing any ASCII string as a [1234567890abcdef]{64} string and you can literally store your money in your mind.

The problem with this approach is that your private key wouldn't be so random anymore, which reduces dangerously the number of possibilities, bringing it down to a brute-forceable set.

Taking it the other way round: if people start to generate addresses based on easy-to-remember private keys, then a group of people can start to pre-calculate the most obvious ones (the amount will depend on my computing power and how much time I spend doing it), check their balance regularly and take their coins.

This is only an impression, though – I didn't do any maths and might be totally wrong (which would be nice!). It would be interesting to check this assertion with actual numbers.

In this guide there are no passphrases, just 64 hex characters randomly chosen by the user
To use passphrases you can use this, but the passphrase isn't enough to retrieve the coins. The program also prints a 10-digits number which is like an additional key, but much more practical because you can store it anywhere (mobile, postit) without being noticed as a 10-digits number is rather common
You can also use the sha256 of one of your file to get a priv key

Jackjack,

WOuld you be willing to update pywallet to support the import of the 22-character private keys I will be using on my physical bitcoins?  I would like to encourage this (or a similar format) for other applications... 22 characters fits well on a small QR code without being ridiculously dense, yet still provides a decent amount of entropy (around 128 bits).

My codes are 22 characters, and the private key is simply the sha256 of the 22 characters as a string, with the following constraints:

1. the first character is always 'S'
2. all the characters come from the base58 alphabet
3. as a guard against typos, all my codes conform to the following rule: the sha256 of (string + "?") will be a hash that begins with eight zero bits (so, first byte is 00 hex).  That is, the string with a question mark appended, so 23 characters.
4. they are printed in the coins in four groups - five,six,six,five characters so they fit on a circle.  There are no separators or spaces between the groups for the purpose of the hash calculation, but the user might enter them anyway.  Respond gracefully.

Why don't you use the privatekey format used by sipa's fork/vanitygen/pywallet/bitbills/etc which is a de facto standard?