Topic: Can you create a Bitcoin address manually? (Read 2844 times)
legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
yeah but why do you need that much entropy when there's only 2^160 addresses?
Quote
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.
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.
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.
Code:
perm :: [Int] -> [Int]
perm [] = []
perm (top:rest) = top:perm [if x>top then x-1 else x|x <-rest]
permN :: [Int] -> Int
permN deck =
let trim = init(perm deck)
n = length trim
in foldl (\acc (c,d) -> (acc+d)*c) 0 (zip [n,n-1..1] trim)
Quote
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.
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.
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.
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 
Was it just to list out all the card names and numbers and then take SHA256 of the list?
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).
Quote
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.
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.
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 a single standard deck of cards.sixty-four 16-sided dice, or eighty-six 8-sided dice, or one hundred twenty-eight 4-sided dice?
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.
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 a single standard deck of cards.
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 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
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 I guess? i.e. for the challenge
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?
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.
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.
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.legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
Oooooooooooooooookkkkkkkkk
Looks like I'll just be using my trustworthy PC to generate addresses.
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.
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.
HP 48 GX or similar ... and reasonably cold too.
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.
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
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.
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.
Oooooooooooooooookkkkkkkkk
Looks like I'll just be using my trustworthy PC to generate addresses.
Nice conclusion ;-) Looks like I'll just be using my trustworthy PC to generate addresses.
Oooooooooooooooookkkkkkkkk
Looks like I'll just be using my trustworthy PC to generate addresses.
Looks like I'll just be using my trustworthy PC to generate addresses.
Jump to: