Bitcoin Forum
May 23, 2024, 07:30:17 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Cold storage questions  (Read 2198 times)
Bernard Lerring (OP)
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 11, 2014, 02:36:16 AM
 #1

Hi there. First post/topic.

I'm about to put coins away in cold storage on a long term, to be forgotten about, basis and have some newbie questions:

1. I understand I can use the bitaddress.org HTML document, copied on a clean USB stick to a live USB version of Linux (Tails) which has never been connected to the web to generate a public address and private key. How do I know that the pair that's generated is unique and hasn't already been generated? What are the mathematical odds of someone coincidentally having the same private key?

2. Is there a "scene" for people using powerful computing technology (high-end GPU's etc.) to generate and test thousands of private keys in the hope that they'll stumble upon some coins?

In short, am I OK to store a couple of coins in a paper document and forget about them for a year or two?

Thanks muchly. I find this site very interesting, even though some of the more mathematical explanations can go over my head.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
May 11, 2014, 03:30:09 AM
Last edit: May 11, 2014, 04:17:18 AM by jonald_fyookball
 #2

I personally would not use bitaddress.org -- how do you know
they arent logging everything themselves?  Or that your
Computer isn't infected with a virus?

(Unless you are using their opensource javascript code
and running it on an offline computer...in which case it is ok.)

As far as brute-forcing private keys, it has been discussed
many times.  The lowerbound is 2^128, which, if you
could try a trillion trillion private keys a second (which
not even the top supercomputer could), it would take
8.9 million years.


Bernard Lerring (OP)
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 11, 2014, 04:26:40 AM
 #3

I just copied the HTML file over to a non-persistent Tails desktop and opened it in the secure browser (Iceweasel, I think). At no time I was connected to any network and I used the "shred -n" command to get rid of anything I had saved, even though this is redundant since Tails claims to not save any data on shutdown.

i thought the HTML (containing the Javascript generator) was open source and presume it has been audited and inspected by those more knowledgeable than me in Javascript/HTML.

Since I ran and shutdown Tails on a laptop that was at no point connected to a network the bitaddress.org page could not have reported any generated data back to anywhere. However, if there's a purer way of generating a key (which includes user generated random content) in the terminal that would be good to know.

As for the second part of your post, jonald_fyookball, thanks. That puts my mind at rest that my private key has a ridiculously minute chance of being spoofed.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
May 11, 2014, 04:31:14 AM
 #4

You should be fine.  The only danger I can see would be if some virus was running , got your key...and broadcast it again when that computer came online.  Seems quite unlikely if you're using tails.

Also btw, the 128 bit security increases to 160 bits if you're using an unspent address.

Bernard Lerring (OP)
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 11, 2014, 04:45:31 AM
 #5

Yeah, running Tails in non-persistent mode from USB runs an identical live environment every time you boot. It won't save any of your previous session; just boots into a fresh OS every time and does a quick memory wipe on shutdown.

I don't use it for regular browsing, just for doing stuff like this so the chance of any malware getting onto the live USB is extremely unlikely. Possibly an even more secure way would be to burn Tails onto a live CD so that it's write protected and boot from that. I think I'll do it that way in future.

Good to know about the extra security bits on a brand new, unused address too. Thanks.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
May 11, 2014, 04:50:13 AM
 #6

Best practice is not to reuse addresses. 
Security can actually drop to 0 bits if
you reuse an address on a flawed wallet
(A wallet that mistakenly doesn't generate
new random numbers in its elliptic curve
calculations)

This is all stuff I leaned myself on the forum
in the past few months.  So happy to
pass it on.  Grin

maxrann
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile WWW
May 11, 2014, 07:29:41 AM
 #7

Have you considered using an Electrum seed passphrase instead? It would prevent you from having to re-use the same address and it would allow you to create a "watch-only" wallet with Electrum or with https://coldmonitor.com
Bernard Lerring (OP)
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 11, 2014, 09:20:21 AM
 #8

I already have an electrum wallet for send/receive transactions and wanted to keep the bulk of my coins offline, as it were.

So I've went down the pen and paper route, sending most of my coins to a paper address and keeping copies in different houses (family members with no idea about Bitcoin). I feel that having a couple of private keys stashed that have never been exposed to the internet is a decent strategy and won't touch them for a long time. When that time comes I'll probably import the funds into a wallet.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
May 11, 2014, 01:21:02 PM
 #9

You sound like you're bright enough to handle bitcoin security, which unfortunately at this still early phase of bitcoin, can be a challenge to the average person.  Welcome to the forum!

ViewSonic
Member
**
Offline Offline

Activity: 116
Merit: 10


View Profile
May 11, 2014, 01:25:56 PM
 #10

I'm about to put my coins away in cold storage on a long term too. You questions and answers to them really helped me
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
May 11, 2014, 01:56:17 PM
 #11

This is exactly what Armory was designed to do.  Why re-invent the wheel?

Remember if you make a mistake, you can easily lose everything.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
May 11, 2014, 01:58:41 PM
 #12

Another good idea is to laminate those paper wallets. 

Bernard Lerring (OP)
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 18, 2014, 07:55:40 AM
 #13

I was just thinking about a possible flaw in my system of creating a paper wallet, as detailed above.

Would it be a good idea once I've generated an address (and matching private key) to use my internet PC to search for the address on blockchain.info before depositing my coins into it?

If blockchain.info comes up with a blank for that address does that mean it hasn't been used and I can go ahead and make my deposit?

If it has been used then someone holds a private key for that address and I can go back to my disconnected Tails live OS and simply generate a different address and key pair.

Is my working correct and is it necessary to check the blockchain before depositing?
Relnarien
Sr. Member
****
Offline Offline

Activity: 399
Merit: 257


View Profile
May 18, 2014, 08:15:28 AM
 #14

I was just thinking about a possible flaw in my system of creating a paper wallet, as detailed above.

Would it be a good idea once I've generated an address (and matching private key) to use my internet PC to search for the address on blockchain.info before depositing my coins into it?

If blockchain.info comes up with a blank for that address does that mean it hasn't been used and I can go ahead and make my deposit?

If it has been used then someone holds a private key for that address and I can go back to my disconnected Tails live OS and simply generate a different address and key pair.

Is my working correct and is it necessary to check the blockchain before depositing?

It is not necessary to confirm if your Bitcoin address currently has an owner. The chances of a collision of addresses occurring, though continually growing, is still very minute. However, you can always do as you suggested if it will ease your mind. Nothing is wrong with being doubly sure when it comes to security.

Let me tell you why I personally think that checking if a randomly generated address is redundant though, just to give you an added perspective. Theoretically, if collisions on Bitcoin addresses are already occurring at this very moment, then it will be much more frequent as time goes on, and checking the address once would be meaningless since it could just as easily be randomly assigned to another person after you had already transferred your funds into it.

Also, an address with no transactions linked to it could theoretically still be owned by someone who has simply not used it yet. For example, Electrum generates at least 5 addresses when you open it for the first time. A casual Bitcoin user can use just a couple of those but still retain access to the unused addresses.
Bernard Lerring (OP)
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 18, 2014, 08:38:46 AM
 #15

Thanks, I was thinking along the same lines of minute chance too.

In theory though, especially if bitcoin becomes mainstream, is there a way to modify the way bitcoin operates to ensure no collisions: both past and future collisions? Someone out there could be auto-generating hundreds of keys a minute for various reasons. As we all know, there is an abundance of dishonesty on the internet where money is concerned.

I realise from previous posts that even if someone were generating pairs in their hundreds or thousands there would still be a very small collision chance, but it's a chance none the less. I would be pretty gutted even if I lost just one BTC due to a collision. That could be a lot of money in the future, or could be next to nothing. I don't want to get into speculation  Smiley
Relnarien
Sr. Member
****
Offline Offline

Activity: 399
Merit: 257


View Profile
May 18, 2014, 10:30:09 AM
 #16

Thanks, I was thinking along the same lines of minute chance too.

In theory though, especially if bitcoin becomes mainstream, is there a way to modify the way bitcoin operates to ensure no collisions: both past and future collisions? Someone out there could be auto-generating hundreds of keys a minute for various reasons. As we all know, there is an abundance of dishonesty on the internet where money is concerned.

I realise from previous posts that even if someone were generating pairs in their hundreds or thousands there would still be a very small collision chance, but it's a chance none the less. I would be pretty gutted even if I lost just one BTC due to a collision. That could be a lot of money in the future, or could be next to nothing. I don't want to get into speculation  Smiley

The Bitcoin protocol is open source technology that was created with the rationale that any potential problems would be dealt with as hardware and software continue to evolve. The collision dilemma is one that has been discussed by people in the community many times before -- and still -- but the prevailing argument is that it will be relatively far in the future before collisions start becoming a major problem, and that it will have been solved before we come remotely close to that point in time. While that point may be debatable depending on one's personal perspective, the truth is that anyone saying differently yet also committed to making Bitcoin work can simply find a solution on his/her own, rendering the prophecy self-fulfilling.

As for "preventing collisions," that is impossible without completely rewriting the Bitcoin protocol. There are a lot of existing Bitcoin wallets, all open source and all easily modifiable. Meanwhile, the number of Bitcoin addresses is finite and their generation is a deterministic process. It's just one of those things when dealing with open source -- the best we could is to work around it, not against it.
Light
Hero Member
*****
Offline Offline

Activity: 742
Merit: 502


Circa 2010


View Profile
May 18, 2014, 12:08:37 PM
 #17

I realise from previous posts that even if someone were generating pairs in their hundreds or thousands there would still be a very small collision chance, but it's a chance none the less. I would be pretty gutted even if I lost just one BTC due to a collision. That could be a lot of money in the future, or could be next to nothing. I don't want to get into speculation  Smiley

I wouldn't worry too much about collisions. It sounds scary but you should be more scared you'll die tomorrow and never be able to spend those coins or give them to the people you love. That is far more likely statistically than getting a collision.

Quote
Statistically speaking, unless the protocol changes to accommodate more decimal places, only 2.1e14 addresses could contain at least one Satoshi, and that's only if everyone only had one Satoshi. If anyone has more (and pretty much everyone who has any has more than one Satoshi), then there are fewer occupied wallets.

Within the set of 2256 private keys, they only map to 2160 unique wallet addresses. So the question is how does 2160 compare to 2.1e14? One in a million? One in a trillion?
The answer is one in 6.9595 decillion. Since "decillion" isn't a commonly used word, I'll save you the bother of having to look it up: it's a one with 33 zeroes after it.

To put that 6.9595 decillion figure into perspective: The Earth has a diameter of 12,742 kilometers, giving it a surface area just shy of 50 million square kilometers. A square kilometer is 1 million square meters, and a square meter is one million square millimeters, meaning the surface area of the Earth, in millimeters, is just shy of 50 quintillion mm2.

So here's the game we'll play. I've got 140 trillion earth-sized spheres. On one of them, I have randomly selected a single square millimeter as the prize winning spot. Find it, and you'll get to spin the prize wheel to see how much you've won. The prize wheel currently has about 22 million spaces. 21 million of them contain less than a dollar. But you only get to spin the wheel if you can find the secret spot on the secret sphere.

Wanna play?

Bernard Lerring (OP)
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 18, 2014, 03:45:01 PM
 #18

Wow, Light! Mind blown, and satisfied, at the same time. Guess I'll stop worrying about collisions and leave it to those that have a greater understanding of how the system works.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
May 18, 2014, 04:08:22 PM
 #19

Wow, Light! Mind blown, and satisfied, at the same time. Guess I'll stop worrying about collisions and leave it to those that have a greater understanding of how the system works.

Here's another fun way to look at it:

The total number of bitcoin addresses is 2^160.

If the world population was 1 trillion people
(instead of 7 billion), and each person had
1 trillion computers in their basement, and each of those computers
was generating 1 trillion unique bitcoin addresses every
second, it would still take 46,343 years to go through
all the addresses.

 

Bernard Lerring (OP)
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
May 18, 2014, 07:20:23 PM
 #20

Yeah, but what about Moore's Law?  Grin

Seriously though, jonald_fyookball, that's a good quote if I ever have to explain to a friend how unlikely a collision can be.
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!