Bitcoin Forum

Not sure this really belongs here, but I did not know where else to post it.

How difficult would it be to create a formula that allows one to create a private and public key using just paper and a pencil?

To me this would be the most secure possible method for making a wallet, as the private key will never have existed on a computer, even one thats offline.

Of course one would also need a hardware random number generator, but that can be easily done.  (Using dice, a falling pen, ect.)

I know the math has to be pretty extreme, so its just a thought.

Well I imagine that creating the raw private key in hex format wouldn't be exceedingly difficult, but deriving the bitcoin address from the private key would be because there is hashing involved.

I've wondered if this was possible myself...even if you could use a calculator

Hashes are impossible by hand...
Wouldn't a LiveCD on an offline HDD-less PC enough?

I haven't looked at the details of the hashing algorithm used to generate the public address from the private key.  However, I don't think impossible is correct.  I mean, everything a computer does can (in principle) be simulated using a very long tape and a pencil (see universal Turing machine).

Im just saying, difficult/tedious != impossible.

Well only the public key needs to be hashed to create an address. You can safely type the public key into a computer to obtain an address.

All you need to do by hand is obtain a private key and derive the public key, NOT calculate the hash.

I am offering a 1btc bounty for someone who can demonstrate a repeatable method for calculating a private key using only paper pencil and brain

Bounty noted.  I am actually working on it right now.

EDIT: Okay, I am ready to claim.  Since you said private key, and not a WIF key or public key, its actually pretty easy.

Here is the method, which requires two dice or any other randomizing method.  Roll the two six sided dice 64 times.  Right down the numbers like this:

If the number is 0-9 right now the number.  If the number is 10-12 right now a-c.  Do this with each roll of the dice and you will get a valid hex private key, such as A9 87 3C 79 B6 D8 70  A0 1B 61 57 78 63 33 89 B4 45 32 13 30 3A A6 1C 20 CC 67 2C 23 36 B3 32 62

This is a valid bitcoin private key.  Note that this does not use all the hex characters, and as such can not generate all possible private keys, but its easy to do with just two dice.

You could also buy a 16 sided dice or something and use 0-F which would be more proper.  If you do it this way, the max address you can use is FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141

nice! do you mind trying to work through some more things such as public key?

You want to play with semantics?

Ok, let's play.

Let's take a human, the super-hero kind, who can:
 a/ Calculate a 32-bit operation in 10 seconds
 b/ Work from midnight to midnight everyday
 c/ Calculate a 32-bit operation without any errors

A hash takes about 5000 32-bit operations. So make it 10000 for ripemd160(sha256()).
That makes (10*10000) = 100k seconds = 38.4 hours = 1.6 day non-stop.
Possible.

Now here comes the fun.

---

This time we take a real human, the super smart kind.

A/ He calculates a 32-bit operation in 30 seconds (please try a 32-bit addition and tell me how much time it took)
This raises the total time to calculate one hash to 115.2 hours

B/ The guy must sleep, so he can "only" work from 8am to midnight.
This makes the total time to calculate one hash equal to 4.8 days.
Still possible.

C/ The lower brain failure rate in the best conditions is 5%. As he's super smart his is only 1%.
The probability of him finding the correct hash on one try is P = 1/2^(100000*1%) = 1/2^1000 ~ 1/10^300

D/ He starts the hashing calculation at birth and will stop at 100 years old.
This is (100*365) = 36500 days of calculation.
One try is 4.8 days, so he has 7604 tries available.
The odd of our super smart guy FINDING AT LEAST ONCE the correct hash in his entire lifetime is then:
  R = 1-Q where Q = (1-P)^7604 = ( 1 - 1/2^1000 )^7604

Basic maths gives that Q > 1 - 7604/2^1000 = 1 - 10^(-297.149) > 1 - 10^(-297)
So R < 10^(-297) < 1/2^986
Yes, R < 1/2^986

---

TLDR

It's easier to crack 6 different bitcoin addresses with only 6 guesses than to a human to calculate a correct bitcoin address hash in his lifetime
Yes, I call that impossible

@jackjack,

Yep.  So I guess that answers all this.  Its not possible to create a public key without some form of computer.

@str4wm4n,

Technically I still fulfilled the requirements for your bounty. My address: 1Hd9sBNf8Z892jRGgrTzL9EuVUEhjfJvVc

 ;D

I was only talking about hashes though, you could follow this post:


If you are REALLY motivated you can do it in a few days I think

http://cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

Is this the public key you obtained from the private key you posted? How did you do it on paper?

No, but he offered the bounty for just the private key.

Where?

Topic: Bitcoin Wallet generation by hand  (Read 207 times)


PROTIP: The private key is super easy to calculate compared to the public key complexity: https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

https://i.imgur.com/f1zd9uE.png

paid the bounty, now how can i get a public key with not using a computer, nearly impossible I gather?

...I was not serious, but thanks man!

Loads of rep to you.

It does look nearly impossible, though if you generate it by hand (because its the best random number generation possible) and then get the public key on an offline machine then you should be fine.

Absolutely impossible unless you are god
https://bitcointalk.org/index.php?topic=286534.msg3081885#msg3081885

would a pocket calculator make it any more feasible ?

One of the TI-84s or should may be able to do it.  (With custom programming, probably.)

.5 btc bounty for a program that will hash working bitcoin addresses and works on a TI-83+

it should also generate private keys using user inputed entropy such as the dice mentioned earlier

Wouldn't a ripemd160 and sha256 function for the calculator be sufficient? I would assume you can do the rest by hand.

The dice method is great!!! Now I can be sure that my key is a really good key with almost 0 chance of collision ;D

You may also want to look into this: http://procbits.com/2013/08/27/generating-a-bitcoin-address-with-javascript

What an easy challenge for a huge bounty, I really should hang out on this forum more. A user just gained about $140 for teaching people how to throw dice.



Just pedantry here, but there's no such thing as a fair 16 sided die. Fair dice can only be made from platonic solids (http://en.wikipedia.org/wiki/Platonic_solid).
http://upload.wikimedia.org/wikipedia/commons/c/c7/BluePlatonicDice.jpg


The idea I had to use the full range of bits would be to throw an 8-sided die and write down the private key in octal format. Each throw gives you 3 bits of randomness so to get 256 bits you need to throw 86 times.

Also, instead of throwing two 6-sided dice you could throw a single 12-sided dodecahedron.

Also, you could throw a 4-sided die and a 12-sided die, together giving you up any number in the range 0-F.

Or you could just flip a coin 256 times.



But generating a private key is the easy part. More interesting is generating the corresponding public key. If I'm not mistake that requires calculating the point multiplication of the private key, I guess it could be done since all the long multiplication and long addition stuff you learn at school still works for hex and octal if you stop thinking in base 10. It would take a couple of weeks I imagine. And you'd want to do it a couple of times to make sure you haven't made a mistake.

Yes, I love semantics!

Sorry, I only skimmed the maths, but as far as I can tell your argument is based on the improbability of finding the right answer and the speed of calculation of a human also taking into consideration the length of a lifespan.

You've certainly convinced me that it's improbable.  But improbable != impossible. 

Really, all I have to do now is employ the 6.5 billion humans in the world at this task and implement a reasonable work-sharing scenario.  :)

Yeah that would make R<1/2^953
It's still easier to crack 6 different bitcoin addresses with only 1000 guesses than to 10 billions humans to calculate a correct bitcoin address hash in their lifetimes.
Your trying to increase the probability by multiplying by 10 billions proves that you really have no idea about the numbers evolved here.

Calculating something is also being sure your result is right. And that is precisely impossible.

My trying to increase the probability by multiplying by 10 billions proves suggests that I have no idea how the numbers evolved here.  Evidence of a proposition is not the same as a proof of that proposition within a model.

In fact, I admitted that I only skimmed your calculations, and I'll further admit that throwing in all humans as workers was a sorta off the shoulder comment made without consideration of the specificity of your calculations.  I'm focusing on the categorical difference between impossibility and improbability.

If your argument is basically this:  X is improbable.  
And my reply is this: X is improbable doesn't imply X is impossible.  
And your reply is this: no, X is very very improbable.  
Then it seems like we're talking past each other.

You said you like semantics.  So do I!  Perhaps we can find some agreement here:

1) An event with probability > 0 is not impossible.
2) A proposition supported only by inductive evidence is not deductively proven.

Cheers!

I wouldn't be so sure. Your private key will probably be full of 7's  :-\

http://hyperphysics.phy-astr.gsu.edu/hbase/math/immath/dice.gif
(from http://hyperphysics.phy-astr.gsu.edu/hbase/math/dice.html).


I'd rather flip a coin 256 times. Or better, 256 coins once (decreases the effect of a biased coin)  ;)

Again

It's not impossible to correctly get a hash by hand once, it's impossible to calculate it in the sense of being sure you have the right result

The bounty has been claimed, but I propose using an unbiased dice generation method.

Use base 6 for the 6 sided dice. Roll it about 100 times (really.) Write it down. Then convert that to hexadecimal and you have your private key with no bias. (Okay, maybe you need another dice roll?)

For example:

1001112400000533003453522130540400324355321453252515013101100231113332152441500 105310450123404240000

becomes

F213DA1F48C5B538B67BB9E25379B1CE0A8C8D8E205B03E3E68BDB35CDECA3A2

Then you plug that in to an offline copy of bitaddress.org on a computer that is never used for any other purpose (or uses a Live CD), and we get this:

Bitcoin Address (compressed): 1A2nR6q3aUQPJKpA2YFXjqRdh6XN8WAxKQ
Private Key WIF (compressed, 52 characters base58, starts with a 'K' or 'L'): L5LH5Sg1reynj5pKbVcUo6uvbQTnxnqQs1W1ghACrgdU5A1WJm3J

If that looks better, you can also send me a coin. If not, uh, I tried. hehe. (coin address in my signature.)

For the dice roll, subtract by 1 to get the base 6 digit.

1 = 0
2 = 1
3 = 2
4 = 3
5 = 4
6 = 5

What is your proposal for the public key?

The public key part is very difficult with just pen and paper. Thus an offline bitaddress. You could use a dedicated offline computer or smartphone for this.

Use 100 dice rolls, convert to hex, then use that as the private key.

At the very least, you are absolutely sure the RNG is truly random and not broken.

I thought this too when I was looking for dice to generate private keys (actually, to generate electrum wallet seeds, but the principle is the same). But actually you are mistaken. The dice need not be platonic. I bought a bunch of 16-sided dice here: http://www.thediceshoponline.com/dice-search/16-sided (http://www.thediceshoponline.com/dice-search/16-sided). They need only possess sufficient rotational and reflectional symmetry, so that each face has an equal chance of landing up. It seems to me, the general idea behind the 16-sided models is adaptable to any even number of sides from 6 up (though for 6 itself you'd prefer a cube, and for 8 that gives you the platonic octahedron anyway).

This is my attempt at a solution.

https://www.youtube.com/watch?v=CzrgJ0jA4dg (https://www.youtube.com/watch?v=CzrgJ0jA4dg)

Does it count as a solution if I designed it using a pen and paper :)

http://www.thediceshoponline.com/dice/4411/Hexidice-D16-Hexadecimal-Dice

Hexadecimal Dice. 16 sided. Roll 64 times. Private key.

Your best bet is to take your private key into an offline computer to calculate it for you.

What am I, chopped liver?  ;)

That's what I've been saying. Offline computer to calculate it for you. Can be an offline Android smartphone or tablet. Dice is your entropy source.


Where can I get one of those? Is that a calculator? On googling, it is a discontinued model. Can you update your request to something I can get today?

And if you include today's smart phones, then we have the solution already. Grab the cheapest model, put bitaddress.org on it, then zap out the antenna or SIM card. Store it in the refrigerator. Cold storage.


An alternative is to use your camera and take a picture of the dice, take a picture of the sky and some random things. Then download those pictures and run it through sha256sum.

I think I'm better off getting the cheapest android unit that can run bitaddress or some app that does the same thing.

Actually a single dark picture (cover the lens with your hand) is good enough. The resulting noise and hot pixels in the image are a good source of entropy, coming directly from the sensor (ie hardware).

well the math is above me lol, but couldn't your 'super-smart' be a little smarter and instead of doing the math himself, be allocated to to the of task simply breaking it up into easier micro chunks of math to be distributed amongst an army of mental sweatshop laborers and then supersmart guy checks over for errors and does the final math on it?  assuming a low amount of errors, it would reduce the time significantly would it not? In some countries right just paying the workers with food (some economical high protein stuff like peanut butter!) would be incentive enough.

note i'm am conscious of 3rd world war/global poverty issues and don't mean to be insensitive here, so please don't interpret as that.

Is there some kind of "hash" that can be easily "calculated" from an human (even if takes some hours...) but not from computer?

Do you mean a hash that a computer can't perform or one that it would take longer than a human?  It would probably have to involve some sort of riddle.  Though the computer in the van in midnight madness could do it quickly...

I don't think this qualifies for a claim.

I don't think this qualifies for the bounty.

You risk all those workers will somehow know the private keys. Someone will take notes and eventually figure out what they are used for.

Just use an offline computer or an offline smartphone.

captcha

I was going to write the order of operations to be made on paper, then I got to RIPEMD-160. No way someone can complete the process (EC generation, EC point conversion, RIPEMD-160 hashing, SHA-256 hashing, base58 conversion and address building) and remain sane.

You would need something like 100-200 pages of paper with boxes printed of them to help you complete the operations, and many many hours...

The EC part seems possible if you are really motivated

There are less operations but the operands are bigger. The hashing though, it will take some time to complete. I will try again later to see if I can write the operations in order.

Write an Android / iOS version of it. Publish source code or make it open source. Problem solved for most people.

If you really want to do it on paper ... Good luck.

Given that doing it purely by hand is practically unfeasible, how about this as a next best option: using our NoBrainr python script (only 25-30 lines of code) on an offline raspberry pi? This can be used with or without dice.

Can I ask why you promote nobrainr so much? Lots of people share scripts on this site but I've never seen someone promote their opensource script quite as much as you do.

Because I think it can help users and hits a sweet spot between security and transparency? Also, I only mention it when it's appropriate to.

Although now you mention it, you may be right, I seem to be a little obsessed with it!  Probably due to the fact that I have a little too much free time on my hands right now. Won't last for long, though...

There seems to be some confusion between ADDRESS and PUBLIC KEY.

The PUBLIC KEY is computed from the PRIVATE KEY using ECDSA.

The ADDRESS is the PUBLIC KEY triple hashed and checksumed.

It is utterly impossible for a human in any reasonable amount of time and with any reasonable accuracy (don't want to be sending funds to the wrong address) to perform the hashing necessary to create the ADDRESS.

However the OP asked about the PUBLIC KEY.  It would seem difficulty but possible to compute the PUBLIC KEY from the PRIVATE KEY.  Then transfer only the PUBLIC KEY to a computer and use a simple program to compute the full ADDRESS.

Sorry for the annoying caps but seems many people can't grasp the difference between PRIVATE KEY, PUBLIC KEY, and ADDRESS.  If you are one of them they are three distinct things. ADDRESS =/= PUBLIC KEY.

Yes, I needed this education.  I thank you death and taxes.

your math is flawed:
assuming 5% error rate per step and 30 secs per step, it takes about 800hours to finish the hashing, doing as following:
calculate each step 5 times, if the 5 results match continue, else start the step again.
the probability to get the right result from this is:
99.999999%,

I've mentioned it in another thread, just roll dice one hundred (100) times, write down that sequence, and use that as the passphrase for bitaddress.org. (or nobrainr, but I have not yet used that tool yet.)

I'm still researching this method, but the problem with the hand method is that even if you generated a pure random 256 bit private key, you still need to add 0x80 at the beginning and check-sum at the end of that key, then do a base 58 encoding to get WIF format private key to be imported into major wallet software. That check-sum involves 2xSHA256 hashing calculation which is impossible to do by hand

Is there any client can import a pure hex format private key so that I can skip the WIF format altogether?

There's no point in caring whether a private key is in hex or WIF if you're importing it into a wallet.  The wallet does hashing on it and so you're not "doing it by hand" and avoiding a computer.  But, I'm sure sx can use your private key in hex format or as a seed, so you can use that if that's your goal.

http://www.swansontec.com/bitcoin-dice.html

Here is a detailed description of using 2 hex dices to generate private key and use some bash script to generate WIF. When I examine the code, it uses openssl to do the hash function, and base58 encoding part is also not easy to read. So the calculation is dependant on openssl functionality, which I would like to avoid if possible

Hmmh. I wrote I piece of code to simulate any fair positive-integer sided die or a deck of cards provided you have a fair 2-or-more sided die or a fairly shuffled deck of cards. I liked the deck of cards thing, it was nice as a dice simulation, no flying parts. Don't know if I can clean that code though if anyone would like to draw cards to make their private key... but it's fun for someone to code. It's a fun exercise to convert the cards to a number while allowing shuffling in the middle etc, suggested for any hobbyist coder.

Maybe it's interesting to note that no finite amount of fair dice rolls with a die that has less than 3618502788666131106986593281521497120401173883721090761956411348172442546698 sides can be guaranteed to give a truly random (with equal chance for all possible keys) private key (similar to a 115792089237316195423570985008687907852837564279074904382605163141518161494336-sided dice roll). Fortunately reality isn't that harsh and more than 100 rolls with a six-sided die are rarely needed   :)