Bitcoin Forum
December 13, 2024, 10:50:42 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Is it neccessary to 'test' new cold storage? Is there such thing as invalid key?  (Read 2022 times)
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
May 12, 2014, 03:18:24 PM
 #21

I've made several cold storage keys (Well not nearly as many as Casascius!) and several of the ones I have made were duds. The way I test them (there's probably a better way) is to send a few microbitcoins to them and then look up the address on the blockchain. If you find the address on the blockchain it's usually good. If it doesn't show up then it's not.

This is nonsense.  Please provide some examples of these bad keys.  If you generated "invalid" keys then it is user error or a bug in your code.  Either way the solution is improved code not random testing.

To OP for ECDSA the private key is a random number less than n and greater than zero.  For Secp256k1 n is
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

any non zero 256 bit value less than n is a valid key.

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


Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
May 12, 2014, 03:58:31 PM
 #22

I've made several cold storage keys (Well not nearly as many as Casascius!) and several of the ones I have made were duds. The way I test them (there's probably a better way) is to send a few microbitcoins to them and then look up the address on the blockchain. If you find the address on the blockchain it's usually good. If it doesn't show up then it's not.

This is nonsense.  Please provide some examples of these bad keys.  If you generated "invalid" keys then it is user error or a bug in your code.  Either way the solution is improved code not random testing.

To OP for ECDSA the private key is a random number less than n and greater than zero.  For Secp256k1 n is
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

any non zero 256 bit value less than n is a valid key.

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

In other words, if you generate 256 random bits for example by flipping 256 coins, it will be a valid key 99.99999999999999999999999999999999999962655% of the time.

Like DeathAndTaxes implied, the only way to generate an "invalid" key is by user error or a bug.  An example of a bug would be if the software used a different key to find the associated bitcoin address.  An example of user error would be generating a private key by rolling die, writing down the numbers on a piece of paper, and then transcribing those numbers incorrectly when generating the bitcoin address.  When I generate cold storage addresses, I "test" all my keys using a second piece of software to the one that created them.  I use this second piece of software to produce a bitcoin-signed message and then check that it verifies to the same bitcoin address that the first piece of software told me.  I think this is a good sanity check if you want to test your keys without making your ECDSA public key known to the network.

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile
May 12, 2014, 05:04:29 PM
 #23

Sorry about the grammar in the title - it was due to space constraints.

Lately I have been creating secure cold storage cold storage wallets using offline key generation and either paper or brain to store the key. It is kind of a scary process because deep down I think there's a chance I might generate an invalid key or mess up somehow and then later I won't be able to retrieve the bitcoins I send to the address. So I go through the tedious process of testing the new address by going through all of the secure/offline methods to send a small amount of coins to and from the address, and verify that it works, before I start sending tons of coins there. Well, as this process is tedious and seems to add an unnecessary layer of risk, I was wondering if it is even necessary.

Is it at all possible to create an invalid private key? Of all 256-bit hex numbers, is each and every one a valid key? Also, is it possible for the algorithm that converts the private key into the public key to mess up somehow? If I wrote down any random 256 bit number, and use (offline) brainwallet to derive the public key, is that sufficient enough and can I start sending my coins to it right away without having to 'test' it first?

not necessarily what you're looking for but you could find a lot of useful info here:

http://falkvinge.net/2014/02/10/placing-your-crypto-wealth-in-cold-storage-installing-armory-on-ubuntu/

and also the BIP on HD wallets could be a worth reading:

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

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
TERA (OP)
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
May 14, 2014, 12:48:22 AM
 #24

So the consensus here is that I should test receiving coins but I don't have to test sending them?
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1008


Core dev leaves me neg feedback #abuse #political


View Profile
May 14, 2014, 02:29:05 AM
 #25

Don't use a brainwallet.  That's terrible.  Use a real wallet, armory or electrum offline.
Can you tell me what is bad about a brainwallet or a paper wallet assuming I am using it offline on tails and creating the key in a much more complicated way than their SHA256(passphrase).

using a brain wallet involves turning natural words into a code. before then encrypting it using standard bitcoin encryption protocols.

this brain wallet convertion method may change, or you may mis-spell the words (EG Some instead of some).

the best solution is to put a verified/clean bitcoin software onto a memory stick. then install onto a clean computer without the internet. and generate private keys from this.

DO NOT rely on brain wallets or wallets that your a keyphrase/seed to generate private keys. as i said before the conversion from phrases into a private key may change in the future.

ONLY store actual proper bitcoin private keys.

I put up a bounty to consolidate electrum seed recovery validation into a single python file.
This will greatly mitigate the risks you're talking about.

I'll make an announcement when its available.




Boussac
Legendary
*
Offline Offline

Activity: 1221
Merit: 1025


e-ducat.fr


View Profile WWW
May 14, 2014, 02:54:44 PM
 #26

I've made several cold storage keys (Well not nearly as many as Casascius!) and several of the ones I have made were duds. The way I test them (there's probably a better way) is to send a few microbitcoins to them and then look up the address on the blockchain. If you find the address on the blockchain it's usually good. If it doesn't show up then it's not.

Actually, yes and no.
You can find a valid bitcoin address in the blockchain for which there is no known private key. An example is 1BitcoinEaterAddressDontSendf59kuE.
However, if you derived the bitcoin address from a private key, then you can spend the coins with the private key.

cp1
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


Stop using branwallets


View Profile
May 14, 2014, 03:43:46 PM
 #27

If you generate an invalid address then you're doing it wrong.  There's no warning to test every bitcoin qt key that it generates for you.  What's different about doing it offline? The only difference is that rolling your own cryptography is always a bad idea.

Guide to armory offline install on USB key:  https://bitcointalk.org/index.php?topic=241730.0
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
May 14, 2014, 05:05:38 PM
 #28

So the consensus here is that I should test receiving coins but I don't have to test sending them?

Well that is the problem with consensus.  Is it a consensus of informed people?  There is no reason to manually test cold storage addresses.  Do you manually test all your bitcoin wallet addresses as well?  The software should be tested with unit tests.  The creation of Bitcoin keypairs and addresses is deterministic.  The cold storage address generator could use the exact same unit tests that the bitcoin-core client does.  Test the implementation to ensure it generates correct output instead of trying to test every usage.  If whatever solution you are using doesn't have unit tests then run away quickly. 
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1008


Core dev leaves me neg feedback #abuse #political


View Profile
May 14, 2014, 05:29:26 PM
 #29

So the consensus here is that I should test receiving coins but I don't have to test sending them?

I just used the electrum cold storage solution.
If you do it properly, you will be secure.

And you can restore your wallet from cold storage
using the seed.

You can also test the process on a small amount of
coins (in a different electrum wallet)
as far as signing an offline transaction,
so you are confident in the process.


jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1008


Core dev leaves me neg feedback #abuse #political


View Profile
May 16, 2014, 10:24:06 PM
 #30

Don't use a brainwallet.  That's terrible.  Use a real wallet, armory or electrum offline.
Can you tell me what is bad about a brainwallet or a paper wallet assuming I am using it offline on tails and creating the key in a much more complicated way than their SHA256(passphrase).

using a brain wallet involves turning natural words into a code. before then encrypting it using standard bitcoin encryption protocols.

this brain wallet convertion method may change, or you may mis-spell the words (EG Some instead of some).

the best solution is to put a verified/clean bitcoin software onto a memory stick. then install onto a clean computer without the internet. and generate private keys from this.

DO NOT rely on brain wallets or wallets that your a keyphrase/seed to generate private keys. as i said before the conversion from phrases into a private key may change in the future.

ONLY store actual proper bitcoin private keys.

I put up a bounty to consolidate electrum seed recovery validation into a single python file.
This will greatly mitigate the risks you're talking about.

I'll make an announcement when its available.




Ended up coding this myself  Grin

Check it out:

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


ShakyhandsBTCer
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


It's Money 2.0| It’s gold for nerds | It's Bitcoin


View Profile
June 14, 2014, 07:03:36 PM
 #31

So the consensus here is that I should test receiving coins but I don't have to test sending them?

You could test the private key by attempting to sign a message with the public address and then use a separate computer/client to validate the signature.

This would be a completely off chain validation.
Beliathon
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


https://youtu.be/PZm8TTLR2NU


View Profile WWW
June 14, 2014, 07:10:33 PM
 #32

Don't use a brainwallet.  That's terrible.
It's only terrible if you're not smart enough to use it correctly. To be fair though, many people aren't.

Remember Aaron Swartz, a 26 year old computer scientist who died defending the free flow of information.
ShakyhandsBTCer
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


It's Money 2.0| It’s gold for nerds | It's Bitcoin


View Profile
June 15, 2014, 05:53:10 AM
 #33

Don't use a brainwallet.  That's terrible.
It's only terrible if you're not smart enough to use it correctly. To be fair though, many people aren't.

Even if used correctly a brain wallet can be less secure then other types of security for wallets.

The only real time when a brain wallet should be used is when there is a good chance that others will have extended access to your possessions.
Pages: « 1 [2]  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!