Topic: This message was too old and has been purged - page 6. (Read 50741 times)

If you check-out this link: http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

apparently some hardware wallets have crappy "random" numbers that are not random at all(a very common problem
with code)

another reason I prefer to just stick with the official client

When you've finished rolling on the floor with laughter (are you really? really?), I'll point out my earlier comments on this thread, to do with a lost wallet containing a reasonable number of bitcoins. There's my vested interest. To clarify - I'm not in the least interested in general cryptography, the mathematics surrounding it, or finding weaknesses in the elliptic curve. If I was, then I would certainly be checking out alot of different resources.

I visit these forums casually, and this thread caught my attention, so I am following it. That OK with you? Or is that "pish" as well?

Rit

You're interested in cryptography "weaknesses" ? R.O.T.F.W.L. !

Well, you've come to the right place. Don't bother with the worlds greatest computer science labs, PHD research or reading military grade specifications - those folks are clueless. Bitcointalk is the bleeding edge and any new developments will ONLY appear on here !! (Specially when it's supplied by a raving Youtube researcher who thinks he's cracked Elliptic Curve DSA cryptography and can't get hs point across for swearing at his telly   )

Seriously though, EK's software is PISH. It couldn't crack an egg without being given the answer to start with.

It's main design objective is not to create history but to create 2 bitcoins from unsuspecting wide eyed victims *.


(Small Print)
* although I'm having a bit of fun with EK and don't wish him any genuine malice, he is fair game since a) he's trying to claim that he's discovered a phenomenon called "weak address space" which actually only exists within the definitions of his own software and b) he's trying to scam people out of 2 bitcoins for a piece of PISH software and that's actually quite a lot of money these days

Just wanted to address a couple of things here about how I seem to be coming accross in this thread....

Firstly, I'm not EK - this is not my experiment, nor do I claim to really understand what he is doing very well.

Secondly, I am not claiming that I have cracked any addresses, or know how to. I simply mentioned that I have been throwing various brute force methods at an address known to me. None have been effective, and I have had no results. This is exactly as I expected, but I'm not yet ready to quit.

This is the reason that I have been showing alot of interest in this thread (and the other thread). If a technique does become known, then I have a vested interest in it.

I pointed out a couple of times that based on the size of the numbers involved that I did not believe any simple brute force technique was going to produce a result, except by accident. However, I do not claim that this is what EK is actually trying. It may be utterly different, and in fact, seems to be a completely different angle.

In short, I don't pretend to understand EKs experiment, I am not trying to argue for or against it, and I am certainly not trying to say that I know better. I most emphatically do not know better

Anyhow, just wanted to clear that up, because I felt that the thread was getting mildly derailed in a couple of places, and I felt this is my fault.

Still watching developments with interest.

Rit.

Folks.

This whole argument is purely theoretical nonsense.

The practical reality is that there is not one single 3rd party generated key that Evil can crack with his software. The flaw in the hypothesis is the point that "it has to be a weak address".

The word "weak" here does not mean "weak" as in "not strong". It is a misnomer. By deliberately generating a "weak" address you are basically telling the software what the private key is (relatively to feeding the hacking software a random address).

Public private key encryption security is based on ** probabilities **. Please put the word "weak" out of your heads and instead consider the fact that you are drastically modifying the solution domain for the address generation algorithm. This changes the nature of the key because it impacts on the probability of solution.

The correct measure of whether a weakness has been found is being able to crack *any* address with a significant probability, not "pre selected" addresses that happen to suit your particular hack algorithm. As Evil said himself in response to my analogy with sandgrains, it's like sending 100,000 people to all the beaches looking for a blue ball. Well that works if you know they have to go to a beach, but the fact is that you don't. Evil's algorithm **assumes** this by arbitrarily picking the rendezvous points.

Watch Evil's video at 0:20. http://www.youtube.com/watch?v=TC43aOdsf4g&hd=1

He says:

my random address generator is... "just generating bitcoin addresses that are potentially weak". The word "weak" here is used as if those addresses have some kind of hackability about them. Whereas what in fact has happened is that Evil has generated addresses deliberately close to the rendezvous points, thereby "telling" the hacking software where the solution domain is. It's a bit like me telling my password cracker that my password contains the letters "t, e, w, y, s, a and r" and then saying - "hey look - it cracked it" ! Well obviously because I basically told the hacking software what the password was, it just had to re-arrange the letters.

i.e. What evil is doing is modifying the data to fit the required result. He is not finding weaknesses in bitcoin addresses, he is creating a set of locks and then creating a set of keys that fit those locks.

Maybe Brady is one of the words?  ;-)

If it is any help, you misspelled that pretty severely. Provided your GF did not also do that and your misspelling it here was not intentional to make it slightly more difficult for others to try and find your passphrase, make sure you spell it correctly if you are using it to narrow the search space:

2,4-dinitrophenylhydrazine

(with or without capital "D" for "Dinitro" as per her habits)

I've seen it, watching the other thread, I've posted the things we should double-check before we can point to ECDSA.

TL:DR; for those who are not watching the other thread: We a getting a shitload of doubles (collisions) in public keys generated from different machines. I'm running 3-4 Linux machines each generating more than 100.000 keys/sec [Edit: each finding about 250 keys/hour which meet EK criteria], and others a doing this also on the massive level. This is, to my knowledge the first massive address generation here where the results a submitted to the central database and checked. We should check now if the lack of entropy has anything to do with this.

Don't worry you posted two words here, you could have posted two more and be safe, there would be 4-8 unknown words in your 8-12 words passphrase. Even if it is only 4, and even if those 4 are from reduced english vocabulary of commonly used of words of 17,000 words, there's 17,000^4 = 83,521,000,000,000,000 combinations left. You would have to reduce it to only 3 unknown words for anyone to have a chance to crack it.

If you are worried about it do not post the transaction or address involved.

Ritual,  Now I have a question for you:

Please give me the transaction id of the transaction where you spent the 1 BTC from your long lost BTC stash.

Maybe understanding exactly how vanitygen works will clear up some confusion:

Use vanitygen to search for the Bitcoin address

1) Create a totally random private key over the entire private key space (random Key_private)
2) Calculate the public key from the private key (ECC Key_public = Key_private * G)
3) Calculate the Bitcoin address (Address = Encode(HASH(HASH(HASH(Key_public)))))
4) Compare the randomly generated Bitcoin address to the regular expression given to vanitygen when you started it
5) If this randomly generated Bitcoin address matches the pattern then print and quit (or continue, depending on flags)
6) Go to 1)

So now maybe you can understand why setting your search pattern to only two or three characters and then doing the rest of the comparison yourself is not better (and is probably slower) than just setting vanitygen to do more or all of the pattern match.

Vanitygen generates one key pair at a time, calculates the Bitcoin address, then compares it to the pattern.  It does not magically generate only the Bitcoin addresses that match your pattern.  That is why the longer your pattern the more time it takes to find one.

Sorry if you already knew this.  Others might not have.

You talking about the server for the rendezvous point thing?

The new c++ script queues them instead of chucking them away when they can't be sent.

To answer your question more directly, it is certainly possible to calculate how many addresses start with a certain prefix. That's just 2^(160-x) where x is the length of the prefix.

The problem is there's no way of knowing which private keys get you that prefix, so you're no better off.

Vanitygen just generates private keys randomly, which are converted deterministically to pub keys and addresses. Unless those hashes and ECC were broken, you're not reducing your search space by specifying that you want Vanitygen to store the addresses that start with 1xyzabc. In other words, there's no way to tell Vanitygen to "only make priv keys that get you addresses near 1xyzabc...".

Unfortunately for your wife, yours is just a brute-force method. Definitely ask her to tell you every possible number, phrase, and character that she may have used for her brain wallet. There's no other way about it.


You're misunderstanding Vanitygen in the same way that Rit is. There's no way of knowing which private key will get you address that starts with a preordained string of characters.

For example, observe how different the addresses are even of very closely related private keys in this list:

http://www.directory.io/

That's the point of the cryptography; you get no information about where to look for the private key if you're only given the address.

I am not a math wiz on this but while we are comparing futile efforts to "win the lottery" with bitcoin I am curious if someone can work out this math.

Is it possible to calculate how many addresses in the keyspace will start with a certain prefix. For example the address 1933phfhK3ZgFQNLGSDXvqCn32k2buXY8a has over 100k bitcoins on it.  If your using vanitygen or some other such tool and generating keys with a target of 1933 how big is that subset of addresses that will begin with that prefix?  Are we talking only 2 lifetimes of the universe instead of 10?

Just curious, this is interesting stuff.

If you're mistaking me for the OP, then I forgive you. That only means that you can't read. Not your fault.

If you're under the impression that I am laying down some sort of challenge, then you're stupid. And that is also not your fault. But it means I won't bother with you.

Which is it?

Now before you answer, I'd like you to consider the following: I HAVE NEVER EVER CLAIMED TO HAVE CRACKED A KEY OR FOUND ANY WEAKNESS IN THE CURVE. This is not my thread.

Rit.

Don't get so upset. I didn't mean to offend you.
I only mean that if you cannot show me how you crack actual keys, then don't waste my time.
Please

With all the respect I can grant you for your comment, which is fuck all....

Don't be so fucking ridiculous.

I'm well aware of what I am doing, and I'd bet a banjo to a barndance that I understand the mathematics behind this better than you do.

I wasn't putting myself up for a challenge, you utter utter moron, I was pointing out that ANY attack on the elliptic curve is futile, as long as it centers on isolating a section of the namespace.

Do you understand now? Or should I draw this in fat crayons for you and then post a picture of it? Or is fingerpaint better?

Try READING sometimes. It helps immensely with comprehension. Really.

Rit./