Generate an address

[jackjack]

Is there a better source of entropy available to the average person that could be used to mechanically generate a private key?

For i<52:

• if 0->31: add the corresponding 5 bits to the private key
• if 31+: run it again

Remove FOUR random bits

[DannyHamilton]

Is there a better source of entropy available to the average person that could be used to mechanically generate a private key?

For i<52:

• if 0->31: add the corresponding 5 bits to the private key
• if 31+: run it again

Remove FOUR random bits

I think I said "available to the average person".

Most of the people that I know have a coin in their pocket or very nearby.  I don't know anybody that owns their own well balanced and maintained roulette wheel.

By the way, how would you choose which 4 bits to remove?

[jackjack]

Running the roulette again of course

[BurtW]

A private key is just a 256-bit random number. (Well, a number between 1 and hex value FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141.)

Where did you get that God awful number?  The actual value of p for secp256k1 is:

p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

I got it from the Private Key page on the Bitcoin wiki. I don't know whether the number is right or wrong, but feel free to update the wiki (perhaps it should have a citation, even?) if the value there is wrong. I apologize for not checking my sources more thoroughly, or at least citing where I was getting my info from.

In any event, it's rather unlikely that a random 256-bit number won't be in the range. If somebody gets heads a ton of times in a row, they may want to double-check the upper bound before using it. (Or, perhaps more likely, check that their coin is fair…)

The integer p specifying the finite field F_p can be found here:

https://en.bitcoin.it/wiki/Secp256k1

which is really just copied from section 2.7.1 "Recommended Parameters secp256k1" on page 15 of this document:

http://www.secg.org/collateral/sec2_final.pdf

I will verify this and then fix the wiki if I am correct.

[jackjack]

A private key is just a 256-bit random number. (Well, a number between 1 and hex value FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141.)

Where did you get that God awful number?  The actual value of p for secp256k1 is:

p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

I got it from the Private Key page on the Bitcoin wiki. I don't know whether the number is right or wrong, but feel free to update the wiki (perhaps it should have a citation, even?) if the value there is wrong. I apologize for not checking my sources more thoroughly, or at least citing where I was getting my info from.

In any event, it's rather unlikely that a random 256-bit number won't be in the range. If somebody gets heads a ton of times in a row, they may want to double-check the upper bound before using it. (Or, perhaps more likely, check that their coin is fair…)

The integer p specifying the finite field F_p can be found here:

https://en.bitcoin.it/wiki/Secp256k1

which is really just copied from section 2.7.1 "Recommended Parameters secp256k1" on page 15 of this document:

http://www.secg.org/collateral/sec2_final.pdf

I will verify this and then fix the wiki if I am correct.

I just answered to your post in the dev&tech forum
It's n because G^(n+1) = G
By the way a private key above n is valid, it's just that it will equivalent to (private key)%n

[DannyHamilton]

The integer p specifying the finite field F_p can be found here:

https://en.bitcoin.it/wiki/Secp256k1

which is really just copied from section 2.7.1 "Recommended Parameters secp256k1" on page 15 of this document:

http://www.secg.org/collateral/sec2_final.pdf

I will verify this and then fix the wiki if I am correct.

The number is found in the wiki here:
https://en.bitcoin.it/wiki/Private_key#Range_of_valid_private_keys

And is frequently stated throughout bitcointalk.org:


https://bitcointalk.org/index.php?topic=157820.msg1672366#msg1672366

- snip -
Also, SHA256 can create a value invalid as an ECDSA private key, "Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key."

https://bitcointalk.org/index.php?topic=211503.msg2222704#msg2222704

- snip -

Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.

The range of valid private keys is governed by the secp256k1 ECDSA standard used by Bitcoin.

https://bitcointalk.org/index.php?topic=165347.msg1727476#msg1727476

Does every number with the right number of bits represent a valid private key?  That seems doubtful to me.

I think there is a range. I found it on the wiki: Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.
- snip -

https://bitcointalk.org/index.php?topic=162666.msg1715086#msg1715086

- snip -
What is the maximum number of private addresses?

2^96  --  https://bitcointalk.org/index.php?topic=24268.0

and "almsot 2^256"   --   https://en.bitcoin.it/wiki/Private_key
- snip -

I assume you mean private keys (not private addresses, there is no such thing).  In that case:

https://en.bitcoin.it/wiki/Private_key

Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.

The range of valid private keys is governed by the secp256k1 ECDSA standard used by Bitcoin.

https://bitcointalk.org/index.php?topic=164687.msg1720529#msg1720529

- snip -
Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.
- snip -

https://bitcointalk.org/index.php?topic=156845.msg1662810#msg1662810

- snip -
its because the prime number chosen for secp256k1 is just a little less then 2^256

0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is that prime number in hexadecimal.

https://bitcointalk.org/index.php?topic=286534.msg3081656#msg3081656

- snip -
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

https://bitcointalk.org/index.php?topic=271486.msg2970259#msg2970259

By the way its not really an upper limit: n+1 is a pretty valid private key, it's just that it's equal to 1 (as n+1 mod n == 1 mod n)

If you generate that way you will end up with keys which are not equiprobable. The difference from uniform is very small, but its a certificational weakness you should avoid.

[BurtW]

Good to know.  I was wrong (and was wrong for a very long time).  Learn something new every day.

[DannyHamilton]

Good to know.  I was wrong (and was wrong for a very long time).  Learn something new every day.

 

It seems that every time I think I finally understand something about bitcoin, I learn that my understanding was somehow flawed.

Even on this matter, I thought I knew what I was talking about when I told people that a number higher than 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 was invalid.  Now today I discover that it is valid, it just isn't recommended to use it because it ends up essentially being some other number based on the modulo of the value.

[johnyj]

casting 2 x 8 sided dice will generate a hex number each time, cast it 16 times will generate a private key

[jackjack]

casting 2 x 8 sided dice will generate a hex number each time, cast it 16 times will generate a private key

Run your solution 30 times

• Each time the result is in [2,3,4,13,14,15,16] (7 possibilities), I owe you 1BTC
• Each time the result is in [6,7,8,9,10,11,12] (7 possibilities), you owe me 1BTC
• Each time the result is 5, nothing happens

Deal?

[J35st3r]

Just roll a d20 and ignore everything above 15 (call 20 as zero). Or just use a d16 (a bit more difficult to come by though, never really was adopted in D&D.)

[DannyHamilton]

casting 2 x 8 sided dice will generate a hex number each time, cast it 16 times will generate a private key

VERY BAD IDEA.

The odds of rolling a combination that adds up to 9 (1,8: 2,7: 3,6: 4,5: 5,4: 6,3: 7,2: & 8,1) is FAR greater than the odds of rolling a combination that adds up to 2 (ONLY 1,1).

How exactly will you ever roll a 0 or a 1?

[DannyHamilton]

Just roll a d20 and ignore everything above 15 (call 20 as zero). Or just use a d16 (a bit more difficult to come by though, never really was adopted in D&D.)

Are dice any more likely to be "fair" than a coin?

It seems that people are far more likely to have a coin handy than 1d20?

[J35st3r]

Are dice any more likely to be "fair" than a coin?

It seems that people are far more likely to have a coin handy than 1d20?

Does it really matter here? The address space is 2^160 (mapped from the 2^256 approx private key space). A little bit of bias in the RNG is not going to make very much difference (and a lot of bias would be pretty obvious ... two headed coin anyone?)

I got a few d20 somewhere (I'm of that generation...), but you could do it properly with d6. Just roll four times (ignoring values 5 and 6) and treat the results as two bits of the byte . Slightly more efficient than tossing a coin (not much), but you need to be pretty good at binary to hex conversion (though if you're doing the EC by hand too, that's the least of your problems...).

[DannyHamilton]

Are dice any more likely to be "fair" than a coin?

It seems that people are far more likely to have a coin handy than 1d20?

Does it really matter here? The address space is 2^160 (mapped from the 2^256 approx private key space). A little bit of bias in the RNG is not going to make very much difference (and a lot of bias would be pretty obvious ... two headed coin anyone?)
- snip -

Sorry. I misunderstood.  I thought you were offering the d20 as a response to the earlier question:

- snip -
Is there a better source of entropy available to the average person that could be used to mechanically generate a private key?

[Dabs]

Or to be completely offline, you can flip a coin 256 times to make the private key and have a calculator and pencil and paper to calculate the public key and address. I want to do it one of these days just to show that it's possible.

I was just about to reply with dice when I saw the table-top game dice.

Is there a better source of entropy available to the average person that could be used to mechanically generate a private key?

According to dice ware and other sites, a really good dice would be "casino" grade dice. Those are usually 6 sided dice.

You just have to use an unbiased method to roll the required number of bits needed. Like roll one dice, 1-3 = 0 and 4-6 = 1. But that's too much work and you'd roll 256 times. Better is to roll 2 or 3 or several at a time to get bigger values (not added together, but representing base 6?)

Personally, what I would do is just use those dice results as a seed for a cryptographically secure random number generator. You'd still need to roll the 6 sided dice about 100 times to equal 256 bits.

[gravitate]

I want to get a coin engraved with my public address and private key. Basically my public address will be shown and the private key will be fully written yet have some characters capitalised/ decapitalised and some numbers that are slightly different.

In total for one full private key generated from bitaddress.org the private key was changed by capitalising 3 letters, decapitalising 2 and changing 1 of the numbers.

So the engraver will see my public address and my private key with a few changes. Are there any risk of my coins getting stiolen?
Thanks

[DannyHamilton]

I want to get a coin engraved with my public address and private key. Basically my public address will be shown and the private key will be fully written yet have some characters capitalised/ decapitalised and some numbers that are slightly different.

In total for one full private key generated from bitaddress.org the private key was changed by capitalising 3 letters, decapitalising 2 and changing 1 of the numbers.

So the engraver will see my public address and my private key with a few changes. Are there any risk of my coins getting stiolen?
Thanks

You've posted this question in multiple places. I've already answered it in your other post:

https://bitcointalk.org/index.php?topic=295898.0

If the engraver is aware of your obfuscation system, then there is a significant risk (perhaps they are reading this forum right now?)

Even if they aren't aware, there is a bit of a risk that they could decide to run a program that iterates over various combinations of substitution.  I haven't done the math, but you are essentially changing only 9 bits of information in an otherwise known 256 bit number.

[gravitate]

Well there is nothing for them to believe it has anything to do with bitcoins you see. They are a normal engravers. I am going to save 1000 GNP on there you see.  From what you say they would have to suspect bitcoin first then at the same time be a programmer. I feel secure that it's unlikely they are not. Thank you for your reply though

[DannyHamilton]

Well there is nothing for them to believe it has anything to do with bitcoins you see. They are a normal engravers. I am going to save 1000 GNP on there you see.  From what you say they would have to suspect bitcoin first then at the same time be a programmer. I feel secure that it's unlikely they are not. Thank you for your reply though

You pays your money and you takes your chances.