Can you create a Bitcoin address manually?

[Enzyme]

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

How's it done?

[matt4054]

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 (Bitcoin Wiki)

[Enzyme]

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

Pen and paper, calculator etc...

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

[matt4054]

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.

[Equality 7-2521]

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

[dabura667]

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

Pen and paper, calculator etc...

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

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.

[sherbyspark]

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

How's it done?

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

[matt4054]

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

[gmaxwell]

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.

[Enzyme]

Oooooooooooooooookkkkkkkkk

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

[dabura667]

Oooooooooooooooookkkkkkkkk

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

Nice conclusion ;-)

[noma]

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.

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

[matt4054]

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

[gmaxwell]

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.

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.

[marcus_of_augustus]

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.

[jonald_fyookball]

Oooooooooooooooookkkkkkkkk

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

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.

[johoe]

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.

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.

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.   I'm not sure if the OP would consider this cheating, as it would not compute a Bitcoin address.

[PrintCoins]

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.

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.

[DannyHamilton]

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

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?

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).

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.

[llanillo]

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?