Bitcoin Forum

Hi Basically I would like to open my own savings wallets without worrying about it.  These will be cold storage with the private key written in code that only myself or family know.
I only have a mac laptop that I have used for many many things that I could not trust 100% in order to generate an address on. Without actually buying a new laptop and using an off line www.bitaddress.org to generate an address please can someone tell me the most secure way of generating an address and private key for cold storage please?

Create a bootable Linux USB stick, use that to boot your laptop, open bitaddress.org, disconnect from the internet, generate the address and write it down / print it in whatever way you want.

Rannesha I would have to wipe my os on my mac then right? Maybe I could do this with my pi

You don't need to wipe your Mac. Linux USB installations allow you to boot and run the full operating system from a USB stick. The harddisk with your Mac installation on it isn't touched (and any malware on it isn't started). Once you're done, restart the machine, remove the USB stick and it'll boot right back to your regular OS.

Of course, using a RPi works just as well.

Well, you seem to want hardware you can trust, but say that you don't trust any of your hardware. So, you need to get your hardware into a state where you trust it, or you need to acquire new hardware that you do trust. Something like a Raspberry Pi may be great for this sort of thing, though on "embedded" kinds of devices you want to make sure that your random number generator has enough entropy to work with.

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.

Wow doing it with a coin is fascinating! Can you post a guide on this? It will give everyone a greater understanding of bitcoins too! Wow that really is intriguing :)

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.) All your computer does to make a new address is pick a new random number, and then do some math that calculates the public key from that number. There isn't any magic to it; it's just math. So, any way that randomly picks 256 bits will work. Computers tend to use fancy cryptographic libraries that find good sources of randomness from the information available to a computer, since they tend to be poor at flipping literal coins.

My comment was a probably-too-long offhand remark that you need some technology that you trust to keep your private key private. Sometimes simple technology is best, since you can see how it works and if it's sending your data elsewhere easily. But even if you were to literally flip coins, you'd want to make sure there wasn't a camera or somebody watching you that would compromise your random number generation. Really it's an analogy for what you need your key generating computer to be doing: picking good-quality random numbers that nobody else can end up knowing.

Calculating the public key would require a crazy amount of motivation
Calculating the address is impossible

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

Heh, I hadn't realized it was a recent topic on the forum.
I did say one could use "a calculator". Presumably, one could balance it being fancy enough to be able to handle EC math, while not being fancy enough that one had to worry about it storing ones key for a long time or getting compromised in some fashion.
And one would probably be more willing to enter one's public key on a "real" computer to hash to generate the address, though you'd probably want to use multiple systems to make extra sure that the address one generated actually corresponded to the public key. The network allows payments straight to public keys instead of addresses just fine, though I don't know of any wallet software that makes doing so simple.

The EC algorithm is actually fairly simple (see JackJack's pywallet for an implementation), but relies on bigints (arbitary percision integers) which may or may not be available on a stand-alone "calculator". As has been said elsewhere, this is an ideal application for a raspberry pi. You don't even need to connect it to the internet. Just download bitaddress.org from the github, transfer it to the pi via a memory stick (or load it onto the boot partition of the OS SD card) and you're good to go. Attach a printer, and your key has never been exposed to the outside world. You should reflash the SD card afterwards, to be sure nothing remains that can be exposed later, destroy it if you're paranoid, and the printer too, you never know what's stored inside the modern ones, but an ancient text-only line printer should be safe  8)

I managed to use VMware free trial to run ubuntu withough having to boot from a usb. Then erased application and wiped my free space.
Will I be safe?

If you ran it as a live-CD (no disk image) you should be fine, otherwise you need to secure-delete the disk image (use sdelete (http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx) from SysInternals ... EDIT OOPS that's Microsoft, mac must have an equivalent utility).

There may be some residual data in your pagefile, so probably best to reboot your mac too (not hibernate as this just makes it worse).

[/paranoia_mode]

lol thanks

Running linux in a VM is pointless if your are worried about the safety of your host system. If someone has access to your host system they have access to everything you are running on it including VMs. You should boot from a live USB or DVD.

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

   = 2²⁵⁶ - 2³² - 2⁹ - 2⁸ - 2⁷ -2⁶ - 2⁴ - 1

Oh, I see, that is the order n of G.  You just copied the wrong number.

So yes, you could flip a coin 256 times and copy down the results into a 256 bit number and as long as your number is less than the (prime) number p shown above it is a valid private key.

A coin is a really bad source of entropy though.

Use 512 coins, and drop them from a height. Unleash a dog/kid into the room to scatter and or lose some coins. Then pick up 256 coins randomly  ;D

I did say "valid", not "good" or "random" or "secure".

Still, flipping a coin 256 times and then directly using the value obtained would be much better than using "stfu!" as your pass phrase to a brain wallet ;)

You're suggesting that a typical coin is not "fair" and will tend to land on one side more often than the other?

I would think there would be enough events adding entropy to the action (flip rotation speed, flip initial height, maximum height, resting height, air flow around the coin, initial side up, axis of rotation, horizontal velocity, etc) that the bias in the coin would have to be pretty significant to have a discernible effect in 256 trials.

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

I got it from the Private Key (https://en.bitcoin.it/wiki/Private_key#Range_of_valid_private_keys) 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…)

http://www.casino-en-ligne-francais.com/images/casino-roulette.jpg

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?

Running the roulette again of course ;D

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

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

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

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

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

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

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

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

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

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

 ;D

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.

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

http://www.gmdice.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/0/2/02557.jpg.jpg

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?

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

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?

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

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

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


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.

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

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. (http://idioms.thefreedictionary.com/You+pays+your+money)

For next time how do you think I can write my private key in code safely but easy enough to decode by hand?

I wouldn't try to encode/decode by hand.  I'd generate a random 256 bit number, perform an XOR between the random 256 bit number and the bitcoin address, then encode both the random number and the result of the XOR in something like base58.  Next I'd have two different engravers engrave two separate items, each engraving one of the two encoded strings.

To redeem, you'd perform a bitwise XOR between the values represented on the two engraved items, and import the result as a private key.

In reality, this is all more effort and risk than I'd prefer.  I wouldn't use an engraver at all, and would find some other method of long term storage that doesn't require me to reveal my address or encoded private key to another person.  If you've got your mind set on involving untrusted people to assist, then I'd want to introduce a significant amount of unpredictable modification to the value that you are sharing.