Topic: most secure savings wallet: NO wallet (Read 4814 times)

This value is called the order of the base point G of the curve: the smallest integer n > 0 for which nxG = O where O is the identity element of the additive group, meaning O is a point such that O+P = P for any P in the group.
Typically, in ECDSA, O can have an infinite y coordinate (for some elliptic curves).
Therefore I would not say that the order of G is equivalent to zero because it would lead people to think that the operand of the group is some kind of arithmetic addition when in fact it is not (it is a geometric addition).

Thoughts ?

Sorry for necroing this thread, but I couldn't leave the previous post as the last post. It makes some bad assumptions. First, while it would take a lot of computing power to crack a single private key generated by this method, it would take much less effort to find a private key generated by this method if a million keys were generated. That is the basic flaw in using any kind of algorithm to generate a private key from a smaller key. Second, given the constant exponential increase in computing power, all the estimates above will be cut by a factor of 100 in only a decade or so.

The only real criteria for the safety of a private key algorithm is whether or not it is more efficient to mine BTC or to look for the private keys. If the method above were to become popular, then it could be more efficient to look for the generated private keys than it would be to mine, and the algorithm would not be safe.

Thanks for this info!
I'll add a warning in pywallet

This is true.  However, there are a fixed number of points on each elliptic curve, and for the secp256k1 curve used by bitcoin, there are fewer than 2^256:

0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

This value is equivalent to 0 and isn't valid.  However, one plus this value is equivalent to 1.  Don't use anything equal or larger than this value as a private key.

YOu can use Casascius Bitcoin Utility (for Windows) to convert between base58 and hex.

I see. Thanks for clearing that up.

Afaik, importprivkey only accepts base58 privkeys


You can use any 256bit number as private key, except 0

Is 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef really a valid privkey?

importprivkey says it's not.


I didn't think you could just use any 256 bit number as private key. Please, someone knowledgable clear this up for me.

Doesn't topic started citing Bitcoin wiki https://en.bitcoin.it/wiki/How_to_set_up_a_secure_offline_savings_wallet ?

This has already been discussed here:

https://bitcointalksearch.org/topic/thoughtcoin-29187

and here:

https://forum.bitcoin.org/index.php?topic=28877.0

Passphrase entropy is not exactly the problem, since most people will likely have a low entropy password on their encrypted wallet file too.  It's the fact that the keyspace of a passphrase wallet can be searched without access to your encrypted wallet file. However, I'm still of the belief that passphrase based wallets have interesting properties that are worth investigating further as discussed in the first link above. Also it's not good enough to bruit force the private key, it is only useful if there is money still in it, meaning for short delay transactions this system could still be effective even against a well funded attack.

Note that all the tools for doing this exist now.

j

P.S. Some people seem to miss the fact that "passphrase" is a term of art with a specific meaning, so just to be clear: http://en.wikipedia.org/wiki/Passphrase

Yeah, it would have to be something obscure. One of my previous password policies was to use ironic quotes from "The Complete Book of Locks and Locksmithing" as my key.

I wouldn't recommend a full quote from a very famous piece of literature either - might have enough entropy word-wise if you make it long enough but it would no doubt be ranked among much lower entropy passwords in any sensibly crafted password cracking wordlist. An adversary having some knowledge about your person might even limit the genres of possible literature etc...

I think the solution to the "secure your wallet problem" is to have a real device. A real virtual wallet. It would be a small device with wifi, a screen and a few buttons with the unique purpose of running a bitcoin client.

Has anyone thought of this? I think it would be really cool if someone starts manufacturing a device like this.

OP's method works, but it will never be user friendly enough...

What about a sufficiently long password? For example: "Twas brillig, and the slithy toves Did gyre and gimble in the wabe; All mimsy were the borogoves, And the mome raths outgrabe" contains more than enough entropy (if I'm doing it right)

Take the polish exchange for example. The owner basically said "Amazon lost my wallet.dat, I can't recover my coins". Then someone suggested to take Amazon harddrive offline and recover wallet.dat.

When people use "Sorry guys, I kinda forgot my exact password, hashing algorithm, and substr offset during my vacation.", I'm afraid someone will suggest taking the owner offline and water-board him until the password, hashing algorithm, and substr offset is recovered.

i just meant that the private key was created using his imagination, and yes you're right it's a race to spend, not a race to import. jackjack has now spent the 20 millies anyway.

Sure it's less secure but at least people using that won't lose/delete/formatc:/etc their wallets definitely and cry "I deleted my wallet.dat, I can't recover my coins, it's Bitcoin's fault" anymore
I think that if each person choses his own function and knows they are weakening his safety, it's remains mostly ok
The problem is indeed if people use it without understanding what they do or if the functions are in implemented in the client
I didn't understand your first post like that

I'll add a NSFNewbies tag in my post

imaginary? it's quite real.

importing is not sufficient, I'd also have to send the coins on.

@jackjack:

Your method's issue is about collisions. With people choosing password eventually some will pick the same password set. (even if a guy just testing password: password).

I'm sorry but that trick only adds a negligible amount of entropy, which is negligible. It doesn't matter what kind of tricks you use, whether you end up with 20 bits of entropy or 200 bits of entropy, you're still greatly weaking the system. Suppose by using lots of passwords, lots of substr, repeated hashes, and salts and you end up with 250 bits of entropy, that's still only 1.5% of the entropy of a real key. Is it worth it to go through all that custom code and memorization just to end up with a private key that's 64 times weaker? Isn't it much safer just printing out the key pair like OP suggested or burning the wallet.dat on a CD?

As for your challenge, you missed my point about mentioning the $900,000 USD reward money. I'm not saying it's possible for an attacker to target your specific password. In fact, I can almost gurantee your address 1KJvYREkZxEgDczTKoEtvrhfkALsFsWKRa won't be brute-forced. I was claiming that if enough people saw your post and adopted your method, the attacker can steal from those people collectively, since they all share the same tiny keyspace.

Sorry if I come off as too critical, but I'm just trying to make sure bitcoin stays secure. If lots of people spoke out critically against mybitcoin in the first place then it wouldn't have ended up the way it did. I believe the only to way to ensure the collective security of the bitcoin eco-system is to harshly criticize any non-secure algorithm, organizational structure, and business practice that gets suggested. Every security compromise and every fraud devalues everyone's bitcoins, and more importantly threaten the future of this cryptographic currency.  

I'll stress it again, it's almost perfectly for safe for jackjack to use his method for himself. But if somehow this method ends up being implemented in the official client and thousands of people start using it, then the bruteforcing will begin and people will lose money and see it as a bitcoin security hole when it clearly isn't. I'm only criticizing it so that this worst case scenario doesn't happen. You're more than welcome to use it on your own.