This message was too old and has been purged

[itod]

Not sure why you felt it smart to post part of your brainwallet and now if you post your address there will be quite a few people trying to crack it although you won't see any of it.  Anyways if you search the forums there was a somewhat reliable guy that can help you crack your brainwallet.

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.

[1715334614]

1715334614

[1715334614]

1715334614

[1715334614]

1715334614

[itod]

Itod the system at http://bitprobing.com has just found the first birthday collisions in the address space. This is a huge issue in my humble opinion which allows implications on the randomness of the address space.

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.

[phlogistonq]

one of the words was "2,4 Dynitrophenylhydrazone". In other words, she was being a smartarse and trying to show off her vocab and education.

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)

[FiatKiller]

Maybe Brady is one of the words?  ;-)

[toknormal]

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.

[Ritual]

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.

[toknormal]

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.

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

[Ritual]

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.

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

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

[FiatKiller]

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

[Ritual]

Fiatkiller - yep, I posted that link on the other thread. I was wondering if EKs research was related, and it seems it probably is, although I lack the knowledge about the subject to see the link.

[toknormal]

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?

No. it is not "pish" as well and I am genuinely sorry you lost your coins. It's not a pleasant experience to be robbed.

At the same time, there is a huge amount of fearmongering drama surrounding the whole security issues of bitcoin and for that matter other cryptocurrencies. It leaves everyone paranoid, convinced that they have been victims of whatever security "hole" is currently under discussion. You've just been caught up in the crossfire of this and I didn't mean to patronise you, even in jest, so for that I apologise.

Regarding the security "fearmongering" though, it's a bit like everyone being paranoid about terrorism when they've actually got nil chance - practically - of ever being a terrosism victim, while at the same time not caring 2 hoots about thousands of road deaths that go on all around them every day.

We need to separate things out. First of all, Nils Schneider's post (http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html ) is dealing with a very different phenomenon than Evil Keneivil's.  The Schneider phenomenon is basically to do with wallets that don't comply fully with the address generation specification (by repeatedly using the same random number to generate addresses). So it's a problem of the wallet, not the mathematics. It's basically leaving the door unlocked and can be put down to "faulty wallet" design.

On the other hand, EK is claiming that there are certain "legitimate" addresses that are somehow "weak" or "more hackable" than others.

My point is that it is irrelevant because his definition of "weakness" is pre-biased to fit his test of hackability. A bit like if I write down a number between 1 and 10, then ask you do guess it. Then you guess the correct number, I can then retrospectively define my chosen number as having been "weak". The reality is that any other number would have been equally secure by probability.

That's why I say that the only test that matters regarding EK's software is to crack an arbitrary, specification compliant bitcoin public key, which he will not be able to do.

(By the way could you point me to your thread where you discuss your coin loss ?)

[escrow.ms]

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.

+1 Couldn't say better.

[Ritual]

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?

No. it is not "pish" as well and I am genuinely sorry you lost your coins. It's not a pleasant experience to be robbed.

At the same time, there is a huge amount of fearmongering drama surrounding the whole security issues of bitcoin and for that matter other cryptocurrencies. It leaves everyone paranoid, convinced that they have been victims of whatever security "hole" is currently under discussion. You've just been caught up in the crossfire of this and I didn't mean to patronise you, even in jest, so for that I apologise.

Regarding the security "fearmongering" though, it's a bit like everyone being paranoid about terrorism when they've actually got nil chance - practically - of ever being a terrosism victim, while at the same time not caring 2 hoots about thousands of road deaths that go on all around them every day.

We need to separate things out. First of all, Nils Schneider's post (http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html ) is dealing with a very different phenomenon than Evil Keneivil's.  The Schneider phenomenon is basically to do with wallets that don't comply fully with the address generation specification (by repeatedly using the same random number to generate addresses). So it's a problem of the wallet, not the mathematics. It's basically leaving the door unlocked and can be put down to "faulty wallet" design.

On the other hand, EK is claiming that there are certain "legitimate" addresses that are somehow "weak" or "more hackable" than others.

My point is that it is irrelevant because his definition of "weakness" is pre-biased to fit his test of hackability. A bit like if I write down a number between 1 and 10, then ask you do guess it. Then you guess the correct number, I can then retrospectively define my chosen number as having been "weak". The reality is that any other number would have been equally secure by probability.

That's why I say that the only test that matters regarding EK's software is to crack an arbitrary, specification compliant bitcoin public key, which he will not be able to do.

(By the way could you point me to your thread where you discuss your coin loss ?)

Fair enough, tok, thanks - apologies to you too if I went off a bit at you.

Wrt the coin loss, it wasn't a theft. The missus had mined some coins way back in the day on her laptop and the wallet was lost when the machine was binned. We know the address but have no means of accessing it. That's all it is. Probably will never see the light of day again, but when EK started this thread, it immediately caught my interest for that reason.

Anywho, thanks for clarifying that it's not related to the Nils Scneider post. Like I said, I'm not at all well-versed in any of this stuff. Just reading along

Rit.

[BurtW]

You said you had 300 BTC and then spent 1 BTC.  During the spend of the 1 BTC the public key for the address contaiing the 300 BTC would have been entered into the blockchain.  So if either:

The address the 1 BTC came from still has the 299 BTC or
The change was sent back to the same address

then you have the public key for the 299 BTC.  If you do then the brute force search for the private key can be sped up somewhat.  Note however that even with this speed up finding the private key with a brute force search is still impossible.

Just for educational purposes, remember the algorithm for finding a Bitcoin address I gave a while back is:

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)

If you know the public key then you no longer need the three hashes and the encoding shown in step 3) that step can be totally eliminated.  The new algorithm would be:

Use a new program to search directly for the key pair

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 public key to the desired public key
5) If they match you are done!
6) Go to 1)

[prezbo]

If you know the public key then you no longer need the three hashes and the encoding shown in step 3) that step can be totally eliminated.  The new algorithm would be:

Use a new program to search directly for the key pair

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 public key to the desired public key
5) If they match you are done!
6) Go to 1)

Using this algorithm would require 2^255 tries on average. Using Shanks' algorithm would require only 2^128 tries (along with O(2^128) space), worst case, currently no better algorithm is known. However, without knowing the public key the dlp-breaking algorithms can't be used, so the only thing that can be done is randomly searching through the whole space, like your first algorithm.

[cr1776]

Can you pm the private key for this one:

1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX


 

[Ritual]

Hah!

Me first me first

[Sukrim]

[serious] Is there a way to visualize distribution of public keys somehow? It might be worthwhile to analyze pubkeys on Bitcoin and other Altcoin block chains that all use the same curve and look for anomalies.

As far as I get this project, it is kinda close to vanitygen and will only find keys that are by _very_ bad luck close to some predefined checkpoints. The question is now if it might be possible to find checkpoints that are close (maybe a bit similar to: http://www.youtube.com/watch?v=IuSnY_O8DqQ) to a lot of generated keys, because there might be a bias in how they are generated - or worse, in the underlying mathematics that forces them closer together than necessary.

This will ONLY work if keys are actually NOT uniformly distributed, something which the OP claims has not really been looked into so far.

[Ritual]

[serious] Is there a way to visualize distribution of public keys somehow? It might be worthwhile to analyze pubkeys on Bitcoin and other Altcoin block chains that all use the same curve and look for anomalies.

As far as I get this project, it is kinda close to vanitygen and will only find keys that are by _very_ bad luck close to some predefined checkpoints. The question is now if it might be possible to find checkpoints that are close (maybe a bit similar to: http://www.youtube.com/watch?v=IuSnY_O8DqQ) to a lot of generated keys, because there might be a bias in how they are generated - or worse, in the underlying mathematics that forces them closer together than necessary.

This will ONLY work if keys are actually NOT uniformly distributed, something which the OP claims has not really been looked into so far.

That appears to be exactly what the OP is investigating in this thread: https://bitcointalk.org/index.php?topic=433522.0;topicseen

I'm not familiar enough with the mathematics of it to really understand the conclusions, but there was a lot of talk about collisions at one point. I don't know how that reflects on the veracity of the program offered in this thread though.

Rit

[Sukrim]

Well, not exactly, what he's doing there is (as far as I understand it) to set a few thousand checkpoints, then create keys and check if they are close to these points - if they are close enough, report them to get paid.

The idea is that you'd get about the same number of keys close to any of these points (as long as they are equally spaced I guess). It's kinda the opposite of what I suggested - not looking at existing keys and see if they show some non-uniform behaviour but creating keys and trying to see how close they are to some points.