This is fun to read because you are all arguing about, essentially, different things.
Some of you are arguing about semantics, in which possible fits the parameters of the mission.
Some of you are arguing about math, in which the probability approaches zero, such that the positive value above impossible cannot be expressed reasonably.
And still more of you are arguing about science, which I must say, is at least the most interesting of the arguments.
Keep going; I'll be back with a beer.
While we all sit around here arguing semantics, math, physics, etc. Those of you that think it is possible can just do it. You can download the program from here: https://bitcointalk.org/index.php?topic=107172.0The download link is back up! Please report back here when you find your first few collisions and be sure and let us know how many BTC you are able to steal from the addresses you find! Can't wait for your reports! |
|
|
|
According to this estimate: http://bitcoinclock.com/The next reward drop will occur about 2016-10-09 So yes, it has been pulled in a bit due to the rapid rise in hash rate. No big deal. The last reward drop was also pulled in by the rapid rise in hash rate when we went from CPU to GPU. |
|
|
|
|
To be exact:
Assume N(t) = the number of Bitcoin addresses that have a positive balance at time t.
The probablity of colliding with one of these N(t) addresses by random chance is:
Probablitycollision(t) = N(t) / 2160
The odds of colliding with one of these N(t) addresses by random chance is:
Oddscollision(t) = N(t) : (2160 - N(t))
Since N is a function of time the probablity and odds are also a function of time.
Since N(t) is much less than 2160 these can both be approximated as the static constant values:
Probablitycollision is about 1 / 2160
Oddscollision is about 1 : 2160
|
|
|
|
|
Check out localbitcoins.com
|
|
|
|
Forgot to mention that they will publish all of the bitcoin addresses online and a status for each coin. Around 50 have been pre-sold. I am buying 5 myself.
If you bought 5 then you should know the price  |
|
|
|
og kush420: I have already said exactly what I want to say: My post addresses the question posted by stating that since it will never be possible to even count from 1 to (about) 2256 by any physical means, let alone count and calculate Keypublic = Keypublic + G [and hash that result three times] it is obviously currently, and will always be, impossible to find a specific key pair by a brute force algorithm.
If you do not understand what I am saying there or disagree with what I am saying then I no longer care. Mostly because I am a cranky old fart who believes that if you cannot be bothered to press the damn shift key so that you can properly spell the first person singular pronoun then I (notice the spelling there) cannot be bothered to answer your posts. As far as randomly selecting a private key that collides with another Bitcoin address goes your odds are better than you think. There are only 2 160 possible Bitcoin addresses (not 2 256) so smoke another bowl of kush 420 and give it a go, you might get lucky. |
|
|
|
|
I can answer the question about the prime numbers. If you set the certainty high enough you can be certain. For example above in this thread the call test.isProbablePrime(1024) is made. This is asking to test if the number is prime within a certainty of 1 - 0.51024
When I try to calculate this number on my calculator I get 1.00
So pretty darn certain.
0.51024 = 5.562684646268e-309
|
|
|
|
That is past my expertise, but a check should be made that b < 7 wouldn't have given a prime order.
ask and you shall... By the way, I ran a little experiment. Given our finite field, and setting a to 0, 7 is the first (counting from 0) value for b that results in a prime order elliptic group. I don't understand GLV well enough to know what restrictions it places on a and b, but if we have to pick a curve where a is 0, it seems like b being 7 would be a logical choice (again, given our finite field).
|
|
|
|
There is no true random. Only exponential.
What? |
|
|
|
With regard to the selection of a and b, from Dan: Also, I read a little more on the subject: the curve parameters (0,7) belong to the class of curves with a=0 which have an efficient endomorphism of order 3 (as listed in the GLV paper). I am curious to know if BitCoin is using GLV method which takes advantage of this feature. I did not know the answer to Dan's question so I asked gmaxwell and he responded to Dan, through me, with: No, the production Bitcoin software uses a completely straight forward curve-generic implementation. However, the possibility of high speed implementations is one of the major attractive characteristics of this curve. Bitcoin uses a zero-trust design where all participating nodes verify all signatures, so the whole network's scalability depends on the weakest full participants. One of our core developers has created a high performance secp256k1 implementation which we may use in the future: https://github.com/sipa/secp256k1This implementation can do around 14k validations per second per core on a modern i7 cpu. (Which makes it about 6x faster than the generic code we use today). One of the barriers in deploying this implementation is having more ECC experienced eyes looking at it. Therefore we know that a=0 on purpose and b=7 is the smallest value that works given a=0. |
|
|
|
|
Sure that would help, but the current generation of brain wallets do not do that.
|
|
|
|
What if someone used dictionary words in his private key and then generated the public key using that private key? It could become very probable
Very true! In fact this very thing has happened many times: 1) Someone creates a "brain wallet" using a simple password. A brain wallet is defined as Key private = SHA256(password) 2) They send some BTC to their brain wallet 3) The BTC are instantly taken, never to be recovered! What is happening is that someone, in fact multiple people, have done the following: 1) Get a huge dictionary of common passwords, millions of them 2) Create brain wallets for every one of these passwords 3) Set up a script that constantly searches new transactions for any transfers to any of these millions of bitcoin addresses 4) If any transfers happen to any of these millions of addresses then instantly "sweep" the funds to one of the thief's other addresses where they collect all the ill gotten booty. So, the leason here is to only create and use brain wallets if you know exactly what you are doing. If you do not know and fully understand the concept of password entropy then do not create and use a brain wallet. Noobs should never use brain wallets. That is all very interesting and very important to know and I am very glad you brought it up but my statement still stands as that is not a brute force attack on a randomly generated key pair, it is called a rainbow table attack on a brain wallet key pair. |
|
|
|
Whats the difference between 1 and 5 confirmations?
4 Blocks. So, the "attacker" would need to solve 5 blocks in a row faster than the rest of the network in order to double-spend the funds. It would cost a lot to attempt it and the chances of success would be very slim. I think after 6 confirmations you can consider the transaction safe from a double-spend. too much detail for a noob 1 confirmation is about 10 minutes so 6 confirmations take about an hour. Your wallet or blockchain.info will tell you how many confirmations have happened. If you buy from someone on localbitcoins.com and do a face to face transfer of funds for Bitcions then you do not have to wait at all. The Bitcoins are transferred instantly from the sellers account on localbitcoins.com to your account on localbitcoins.com See my response here for a guide to localbitcoins.com: https://bitcointalk.org/index.php?topic=288051.msg3087780#msg3087780 |
|
|
|
I was going to write this up but it is easier to find it already written up and have you read it there and them come back here for further discussion: https://bitcointalk.org/index.php?topic=233503.msg2474798#msg2474798Like I said this has all been discussed before, including trying to agree on a useful definition of the word "impossible" and "never" |
|
|
|
whatever a private key is, i dont even know, a string of characters, yes or no, can it be written on paper? can i computer compute the characters? then it is possible unless you have a reason otherwise
What exactly are you claiming is possible here? Be specific. |
|
|
|
if you claim something is impossible when it is not against the laws of physics (and even if it is against those, it may be possible to go to other universe!) you are the one making the claim. i am saying anything that is within the law of physics can happen.
Excelllent! Can we agree to stick to our universe for the time being? Sticking to this universe I am saying exactly the same thing you are saying: i am saying anything that is within the law of physics can happen.
Only it turns out that within the laws of physics (in this universe) it is not possible. |
|
|
|
consider the largest number our ancestors had thought of only 500 years ago? 2000 years ago? maybe even a million, but a speck of nothing compared to the longest number we can computate today
Sorry, did not follow your point here. |
|
|
|
with quantum computing in the distant future there is no reason to say it could not happen
You have made an assertion "with quantum computing in the distant future there is no reason to say it could not happen" Now explain yourself, prove it, give a reference, something. Otherwise it is just an opinion. I made the assertion: My post addresses the question posted by stating that since it will never be possible to even count from 1 to (about) 2256 by any physical means, let alone count and calculate Keypublic = Keypublic + G [and hash that result three times] it is obviously currently, and will always be, impossible to find a specific key pair by a brute force algorithm.
Which I can prove and has been proven many times in the past in dozens of other threads just like this one. |
|
|
|
Ok, our friend Dan at SECG is really trying to dig into this and find out exactly how the random curves were generated. He has asked me to narrow down the search to the curves we are actually interested in so he does not waste time researching curves we do not care about. So, I need a list of the random curves that we actually care about - or maybe people have stopped caring about NIST/NSA random curves since the one we use is not a NSA/NIST curve.Here is what he has done and found out so far in his preliminary analysis: Yesterday, I dug a little into this:
I extracted the seeds from the LaTeX source, using a not very careful grep search, and found 22 seeds (some of which are now commented out in SEC2). I may have missed some seeds whose LaTeX did not match my criteria.
Twelve seeds contain the ASCII string “MinghuaQu”, but in some cases they are shifted by 4 bits. I concluded that these 12 were not NIST curves, and that the remaining 10 curves must be NIST curves.
I believe that the 12 seeds containing “MinghuaQu” are curves are mostly 163 bit or smaller, so I doubt that you are considering them.
So far, I have not detected any clear pattern in the remaining ten seeds, but I have not tried hard, mainly I suspect that they are the output of some PRNG, and therefore such tests would likely fail. My main check so far was to compare the sorted set of byte frequencies among the 400 seed bytes to the same statistic for random sets of 400 pseudorandom bytes. A few trials of the random sets had a higher maximum frequency, and some had a lower maximum frequency. I did not calculate any kind of P-test. The point of this test was to see the seeds were some byte-encoding which might favour some particular bytes. I have done to nothing examine the order of the bytes.
Again: many of the smaller curves are now absent from SEC2 version 2.0, which has 11 random curves, 10 of which are NIST curves.
Best regards,
Dan
|
|
|
|
|
Show Posts
