Bitcoin Forum

I've thought about this and I'm up for the challenge :)

How's it done?

What does 'manually' mean, pen and paper only?

Basically, creating an address means creating a public/private key pair and encoding the pubkey to base58. So of course it can be done, at least theoretically, with pen and paper only.

See Technical background of version 1 Bitcoin addresses (https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses) (Bitcoin Wiki)

Pen and paper, calculator etc...

As long as it's not made by an application.

OK yeah then just look up 'How to create Bitcoin Address' on the Wiki page linked above.

Relevant thread: "Can I create a Bitcoin address with pen and paper?" - https://bitcointalk.org/index.php?topic=816123.0

Pen and paper would take days.

http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html
This is ONE of the hashing algorithms (SHA-256) and this man says he could do 0.67 hashes per day.

The process of generating a bitcoin address by hand (pen and paper) would be the following.

1. roll a 6 sided dice 99 times.
2. write down each result, writing a "0" for every 6 that comes up.
3. take this long string of numbers from 0-5 and convert it from base 6 to base 10.
   a. This means starting from the first non-zero digit on the left, multiply it by 6 then add it to the next digit, then multiply by 6 then add to the next digit... etc. until you get a long number with digits from 0-9.
4. Now you will have to calculate the public key. This is more easily done if the private key (the long number you made) is in binary form (1 or 0) so convert the number to binary.
5. Use the ECDSA point doubling formula and point addition formula on the generator point to get the public key. This will probably take a few days.
6. Convert the public point's x and y value both into binary. Pad each of them with 0s on the left hand side in case they're shorter than 256.
7. add 00000100 to the far left, then the padded x, then the padded y.
8. follow the video I linked above to perform a single SHA256 on the binary string created in #7
9. once you get the single 256 bit binary string... you must then perform the RIPEMD160 hash algorithm on it.
10. once you get the 160 bit length hash from it, add 00000000 to the far left of it... hold this string for later. We will do two things to it.
11. perform a SHA256 on the string from #10, then perform ANOTHER SHA256 on the result. (double SHA256)
12. take the 32 bits on the far left of the result from #11 and add it to the far right of the result from #10
13. For every 8 zeros on the far left of the result of #12, write down a number 1 on a piece of paper. Then convert the left over bits to base 58 as per the bitcoin base 58 specification (it's slightly disorienting if you're doing by hand, as 0 is represented by 1, 1 is represented by 2, 57 is represented by z etc...)
14. now you have your bitcoin address. To format your private key in the widely used WIF format, perform #10-#13 on the binary private key from #4... except instead of sticking 8 zeroes to the far left, add 10000000 to it instead.

Ofcourse you can but can't use it, but if you need a phrase in it, then you use vanity generator to generator bitcoin addresses like
1bitstampisback821hjdnbj232fmk2f23nfjk

I think OP implied creating a valid address, i.e. generating a valid public/private ECDSA keypair and the rest of the algorithm described above, not just a bogus address (vanity or not) with a valid checksum.

And yes, you can use it, although you would have to import the key into a client for practical purpose, unless you want to compute and process every message with pen and paper too, and use something like netcat as your network client ;)

With pen and paper it could be done maybe a week of hard work, at least if you also allowed yourself a table (like a big printed book of precomputed EC points).

You'd probably want to run the whole computation multiple times to be sure you didn't make an error.

Oooooooooooooooookkkkkkkkk

Looks like I'll just be using my trustworthy PC to generate addresses.

Nice conclusion ;-)

Is there a guide on how to do so? I am a non techy person and would be interested in knowing more about it.

The post from dabura667 above (#6) is probably about the closest thing to a guide that you'll ever get.

Anyone doing this would be doing it for the beauty of the challenge, and at least descent skills in math/crypto/CS is a prerequisite. With all due respect, I wouldn't start such an adventure if you are a non-techy person as you say, unless you are totally immune to frustration ;)

I think this is basically intractable manually if done naively. You're talking hundreds of millions of 32 bit operations. Even if you were able to retire one per second and worked 12 hours per day you're talking 6+ years.

Thats why I suggested a book of pre-generated G multiplies.  You'd also need to do the arithmetic with jacobian coordinates to avoid performing a modular inverse for every operation. Based on timings people gave for sha256 by hand, I think it could be gotten down to a week or so, though fiddling around with the numbers a bit I'm less sure.

A programmable calculator that uses RPN makes it more practical but 'closer' to the numbers, so to speak.

HP 48 GX or similar ... and reasonably cold too.

you could still create your private key manually... it's more of a feasible task for a human and has the benefit of using offline generated entropy.

I think hundreds of millions for the naïve point doubling/addition formula is a few magnitudes too high.  My guess is a few millions at most.  I count approx. a thousand 256-bit modulo multiplications and 380 modulo divisions in my naïve implementation.  The divisions are probably the most expensive ones, but I think each should only take a few thousand 32 bit operations.  You can avoid most modulo divisions by working with fractions at the cost of a few more multiplications.

Still you need a few days (and a few more to check your result).

And you don't need to compute any hash if you use the old send to pubkey outputs, this should save you a few days. :D  I'm not sure if the OP would consider this cheating, as it would not compute a Bitcoin address.

Wouldn't it be more efficient to just use 10 sided dice? This way you can skip some conversions?

or even more crazy, just take $10 in pennies, shake them in a bucket, dump them out and line them up. Not sure how many bits you would need, so I just guessed $10 would be enough (1000 pennies).

So, there would be a way to create a private key without doing any math and just entering 1's and 0's for heads and tails.

Now, this is what we need:
Starting with a bucket of dumped out spread out pennies (so none are overlapping), take a picture, have some software to recognize heads and tails, and convert the result to binary. Though perhaps just looking a the bits in an sha of an image from a lava lamp would be sufficient.

Since you are trying to create a 256 bit number typically represented as either Hex or base58, wouldn't it be more efficient to use either:
sixty-four 16-sided dice, or eighty-six 8-sided dice, or one hundred twenty-eight 4-sided dice?


That's far too many.  You only need $2.56 as long as all the coins are "fair" and are not intrinsically predisposed to land on a particular side.

Why dont just go to coinbase or blockchain and create a bitcoin wallet.... simple... because creating one manually is like wut? why would you want to do that?

For the same kind of reasons as the guy who ported Quake to an oscilloscope (https://www.youtube.com/watch?v=aMli33ornEU) I guess? i.e. for the challenge

Lol that's actually pretty nice ... well good luck to him ..  i don't know how to help him anyways he surrendered xD

Or a single standard deck of cards.

I know we've discussed this before (I even considered including it with my dice suggestions), but I can't seem to remember the method of converting card suits and values to a 256 bit value.

Was it just to list out all the card names and numbers and then take SHA256 of the list? Or was there some way of assigning bit values to the cards?  I left it out of my suggestion, because I couldn't remember how to do it.

That is the easiest and most direct.  It is slightly less than 256 bits of entropy (225 bits for 52 card deck, 237 for 54 card deck).



You probably could but it would be tedious.  I never came up with any such system.  At some point one needs to trust something.   Still if one absolutely needed to generate the private key by hand only then the simplest (although not the most efficient) would be to just look at the suits but it would require at least 3 (4 is probably better) passes through the deck.

You can... but doing some complicated elliptic curve math and then manually hashing the address with two different hashing algorithms sounds like a lot less fun than having a computer generated one :P

It is possible to assign a bit value to permutations, but I couldn't tell you exactly how to do it. You can't assign bit values directly to cards (at least in the way I'm thinking), because 52^52 > 2^256. It is very similar to Project Euler's Problem 24 (https://projecteuler.net/problem=24). By analogy for a 3-card deck: assign each permutation a number value.
1: 012
2: 021
3: 102
4: 120
5: 201
6: 210
Represent this as a 3-bit value. That's your private key, with ~2.6 bits of entropy. This analogy can also show you why a straightforward conversion like "represent each card as a base 3 digit in the number, then convert to binary" won't work: 222_3 = 26, which would require 5 bits to store in binary, not just 3.

If you use permutations of a deck of cards you get 52! possibilities which is <2^256. You need a few more cards.
To convert a given permutation to a number with a pen and paper you can do this using 1 2 0 as en example
- go from left to right, write the digit you see and then change the number to the right by subtracting 1 to every number that is greater than that digit

1 2 0 -> first digit 1, rest is 2 0 -> write 1, update the rest to 1 0 -> now we have 1 1 0
1 1 0 -> second digit is 1, rest is 0 -> write 1, the rest doesn't change -> final list 1 1 0

- ditch the last digit => now we have 1 1
- keep an accumulator. set it to 0 => acc = 0
- go left to right, pair the digit with a counter that starts at the length of the list (here 2) and decrements by 1 =>
  + every step, sum the digit with the acc and multiply by the counter
  + store the result in the acc
  => step 1: acc = 0, cnt = 2, digit = 1 => acc = 0 + 2*1 = 2
  => step 2: acc = 2, cnt = 1, digit = 1 => acc = 2 + 1*1 = 3

The final value of your acc is your permutation number.

yeah but why do you need that much entropy when there's only 2^160 addresses?