Topic: This message was too old and has been purged - page 5. (Read 50741 times)
This message was too old and has been purged
This message was too old and has been purged
At least Evil-Knievel and prezbo got the same number...
Evil, can you sumarize what you have found with all of your "mining". There was rumors of collisions then nothing. What is happening there?
Evil, can you sumarize what you have found with all of your "mining". There was rumors of collisions then nothing. What is happening there?
This message was too old and has been purged
Where did you get this number? It looks wrong to me.
Sorry, you're right. Copy/paste error from a Python shell! prezbo gave the correct number.
The number I posted is the total number divided by 2560000000 -- in other words, 1 over this number gives you the probability of ever finding one of Evil-Knievel's so-called "weak" Bitcoin addresses in the wild. Practically speaking, these addresses are just never gonna happen.
Meanwhile, there are 45231284858326638837332416019018714005014673546513634524455141852155 possible Bitcoin keypairs.
Where did you get this number? It looks wrong to me.
Meanwhile, there are 45231284858326638837332416019018714005014673546513634524455141852155 possible Bitcoin keypairs.
Do you have mathematic proof for this or are you just guessing that really every point on that curve can be reached?edit: it's actually 115792089237316195423570985008687907852837564279074904382605163141518161494337, which is very close to 2^256.
Meanwhile, there are 45231284858326638837332416019018714005014673546513634524455141852155 possible Bitcoin keypairs.
Do you have mathematic proof for this or are you just guessing that really every point on that curve can be reached?
For Evil-Knievel's demonstration to work, you need to use his pseudorandom number generator (PRNG): https://bitcointalksearch.org/topic/m.4746108
His PRNG only generates from a set of 2560000000 possible values: https://bitcointalksearch.org/topic/m.4809894
Meanwhile, there are45231284858326638837332416019018714005014673546513634524455141852155 115792089237316195423570985008687907852837564279074904382605163141518161494337 possible Bitcoin keypairs.
The probably of his tool cracking a real public key, in the wild, is virtually zero. You are more likely to have a meteor land directly on your house, on the same day, four years in a row.
Evil-Knievel is insulting everyone's intelligence, wasting our time, and trying to con somebody out of 2 BTC.
His PRNG only generates from a set of 2560000000 possible values: https://bitcointalksearch.org/topic/m.4809894
Meanwhile, there are
The probably of his tool cracking a real public key, in the wild, is virtually zero. You are more likely to have a meteor land directly on your house, on the same day, four years in a row.
Evil-Knievel is insulting everyone's intelligence, wasting our time, and trying to con somebody out of 2 BTC.
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.
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.
[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.
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
[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.
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.
Hah!
Me first me first
Me first me first
Can you pm the private key for this one:
1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX
1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX
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:
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. 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 Keyprivate)
2) Calculate the public key from the private key (ECC Keypublic = Keyprivate * G)
3) Calculate the Bitcoin address (Address = Encode(HASH(HASH(HASH(Keypublic)))))
4) Compare the randomly generated public key to the desired public key
5) If they match you are done!
6) Go to 1)
1) Create a totally random private key over the entire private key space (random Keyprivate)
2) Calculate the public key from the private key (ECC Keypublic = Keyprivate * G)
4) Compare the randomly generated public key to the desired public key
5) If they match you are done!
6) Go to 1)
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:
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:
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 Keyprivate)
2) Calculate the public key from the private key (ECC Keypublic = Keyprivate * G)
3) Calculate the Bitcoin address (Address = Encode(HASH(HASH(HASH(Keypublic)))))
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)
1) Create a totally random private key over the entire private key space (random Keyprivate)
2) Calculate the public key from the private key (ECC Keypublic = Keyprivate * G)
3) Calculate the Bitcoin address (Address = Encode(HASH(HASH(HASH(Keypublic)))))
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 Keyprivate)
2) Calculate the public key from the private key (ECC Keypublic = Keyprivate * G)
3) Calculate the Bitcoin address (Address = Encode(HASH(HASH(HASH(Keypublic)))))
4) Compare the randomly generated public key to the desired public key
5) If they match you are done!
6) Go to 1)
1) Create a totally random private key over the entire private key space (random Keyprivate)
2) Calculate the public key from the private key (ECC Keypublic = Keyprivate * G)
4) Compare the randomly generated public key to the desired public key
5) If they match you are done!
6) Go to 1)
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 ?)
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.
Jump to: