Pages:
Author

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

legendary
Activity: 1260
Merit: 1168
This message was too old and has been purged
legendary
Activity: 1260
Merit: 1168
This message was too old and has been purged
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
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?
legendary
Activity: 1260
Merit: 1168
This message was too old and has been purged
newbie
Activity: 3
Merit: 0
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.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
Meanwhile, there are 45231284858326638837332416019018714005014673546513634524455141852155 possible Bitcoin keypairs.

Where did you get this number?  It looks wrong to me.
sr. member
Activity: 430
Merit: 250
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?
The group order is known and is equal to FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 in hex form, however I don't know if that's equal to 45231284858326638837332416019018714005014673546513634524455141852155.

edit: it's actually 115792089237316195423570985008687907852837564279074904382605163141518161494337, which is very close to 2^256.
legendary
Activity: 2618
Merit: 1007
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?
newbie
Activity: 3
Merit: 0
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 are 45231284858326638837332416019018714005014673546513634524455141852155 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.
legendary
Activity: 2618
Merit: 1007
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.
member
Activity: 84
Merit: 10
[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
legendary
Activity: 2618
Merit: 1007
[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.
member
Activity: 84
Merit: 10
Hah!

Me first me first Smiley
legendary
Activity: 4214
Merit: 1313
Can you pm the private key for this one:

1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX


 Grin
sr. member
Activity: 430
Merit: 250
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)

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.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
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 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)
member
Activity: 84
Merit: 10
legendary
Activity: 1274
Merit: 1004
legendary
Activity: 3066
Merit: 1188
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 ?)

member
Activity: 84
Merit: 10
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.
Pages:
Jump to: