Topic: Large Bitcoin Collider (Collision Finders Pool) - page 14. (Read 193124 times)
Let's discuss that on Reddit, so that you are more comfortable. See the post, it has new comments.
Any more questions?
Well, yes.
The point of the post (which you didn't read carefully) is - why do you eval() the server's reply? That's a blatant backdoor.
Good. I really would appreciate it, if you would indicate, which of your allegations you consider answered and - perhaps even - admit you might have been wrong or oversuspicious. Call it courtesy and keeping me in favorable mood to answer your petty requests.
I am answering some of the things on reddit too, but it feels stupid to do that here and there like a parrot. So As for the evil eval you are so concerned about, let me just quote the Reddit answer:
Quote
Well - my fellow coding apprentice - how would you handle the case where the client is potentionally compromised by code tampering (because available as an easy-in-editor-to-modify script) and any hard-coded operation of like "remove myself" could have been eliminated? And how actually is this more a loophole than the WHOLE code auto-updating itself?
If you have a better proposal, I'm all ears.
Rico
Any more questions?
Well, yes.
The point of the post (which you didn't read carefully) is - why do you eval() the server's reply? That's a blatant backdoor.
https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/
You can remotely execute arbitrary code on client systems without any verification from that user.
Very scummy indeed.
You can remotely execute arbitrary code on client systems without any verification from that user.
Very scummy indeed.
rico666, there's a backdoor in the client and you can't deny that.
https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/
https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/
I think I can.
You wrote that Reddit article? If so, fine - let's cope with it here and now.
1)
Quote
Answer: wrong secret.
Yeah - people have really trouble to set up a secret (aka password), so they see this error message often. This is normal program operation like "wrong login" and the like. So I do not see where this would make up for some malicious behavior.
2)
You modified LBC and wonder why
Quote
Answer: malformed request.
orQuote
Answer: challenge failed.
different error messages each time? Let me enlighten you from the server code:
Code:
my @messages = (
'error 0x567',
'malformed request',
'insufficient',
'perm withdrawn',
'gen checksum',
'wrong response',
'challenge failed',
'',
);
... and later then ...
if (!check_quine($version, $quine, $intquine, $mode)) { # if the quine(s) transferred are wrong
log_lbc("PUT-NIL: tampered ($id-$intid)"); # log it
return decorate_answer({ # and inform client
nil => $messages[int rand(7)], # return message intentionally confusing
});
}
Please observe the comment.
I am really sorry if this pissed you off.
So to sum up: you modified the LBC and wonder about this behavior, although it's documented in the manual to not modify the source.
3) Death kiss - yadda yadda
Same department. The client checks it's own source code and will behave with various intensity of response to code tampering
Up to the point where the client deletes itself from your disk if you're driving your tampering ambitions too far.
Yes, for that it needs to checksum it's own source. Cases like this have also been documented here in this thread.
Any more questions?
Rico
rico666, there's a backdoor in the client and you can't deny that.
https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/
https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/
Welcome Nitrado_ in the top30 - your gpuauth has been delivered.
You should know, that arulbero successfully planted a proposal in my head how to potentially double the GPU-generator keyrate (still with double the addresses per key) and that's what I'm working on right now. Only interrupted by some funny comments here and there I choose to answer.
Providing faster GPU generators to people with gpuauth is one thing, but finding a way how to enable all pool participants to tap a keyrate their hardware potentially provides with keeping fair balance is another. Therefore
As one can see, with some CPU-steam, it's possible to get into the top30 quite quickly. With a little bit more CPU steam, it's even possible to dominate the LBC keyrate.
The pool is still in an early phase - comparable to when CPU mining was still a thing - and running way below its potential speed. This situation will change over time and as such it will become harder and harder to get into the top30 to the point where it may become infeasible with CPUs. Because everyone in the top30 will have a GPU generator at their fingertips.
Now - while there still is the "fork out 0.1 BTC or provide some significant contribution" route, barring people from having access to the GPU client is counter-productive for the pool speed. You could say at the moment, the pool is running in "voluntary choke mode". OTOH - there is a fairness I feel is due in respect to the early adopters of the pool who collected Gkeys with the sweat, tears and blood of their poor CPUs. Because the number of Gkeys delivered is kind of a currency within the pool defining your "weight" when it comes to some disbursal, this is not just some "ideal" concept, but has direct monetary consequences.
There are two modes of operation I can imagine for people using GPUs:
a) A "Gkeys-tax" to the early adopters. For the 1st xxxx Gkeys of the GPU newbie operation, yy% of their keyrate would be attributed to the early adopters. It's kind of "proof of stake".
b) A "Janitor-mode" for the GPU-Newbies. For the 1st xxxx Gkeys of their GPU operation, their clients would be assigned to do "janitoring work" in the pool. I.e. search block intervals that would be for redistribution else. (Promised, not delivered work), search areas that are unlikely to contain any finds, but have to be searched anyway etc.
Personally, I have really no preference. Both require some extensive coding to be done right, but the coding needed to implement a) and b) has to be done anyway for other features of the pool I'm working on, so I leave this for discussion to the pool participants. If there is no discussion, I will decide. While I do not have a preference, I tend to b) only because the coding of the features required for this promises more fun to me personally at the moment.
I'm a disciplined guy though, so I'm used to do "less fun"-work too.
I'm a eager proponent of freedom of choice, so often when presented with a) or b) I tend to ask about c) myself. Of course, even if we implement either of these, there still is the choice to just use the CPU generator and do as you'd do without a/b. So it's merely a new way how to get to a GPU generator.
Please comment.
Rico
You should know, that arulbero successfully planted a proposal in my head how to potentially double the GPU-generator keyrate (still with double the addresses per key) and that's what I'm working on right now. Only interrupted by some funny comments here and there I choose to answer.
Providing faster GPU generators to people with gpuauth is one thing, but finding a way how to enable all pool participants to tap a keyrate their hardware potentially provides with keeping fair balance is another. Therefore
Request for Comment: "gpuauth for Newbies with a condition"
As one can see, with some CPU-steam, it's possible to get into the top30 quite quickly. With a little bit more CPU steam, it's even possible to dominate the LBC keyrate.
The pool is still in an early phase - comparable to when CPU mining was still a thing - and running way below its potential speed. This situation will change over time and as such it will become harder and harder to get into the top30 to the point where it may become infeasible with CPUs. Because everyone in the top30 will have a GPU generator at their fingertips.
Now - while there still is the "fork out 0.1 BTC or provide some significant contribution" route, barring people from having access to the GPU client is counter-productive for the pool speed. You could say at the moment, the pool is running in "voluntary choke mode". OTOH - there is a fairness I feel is due in respect to the early adopters of the pool who collected Gkeys with the sweat, tears and blood of their poor CPUs. Because the number of Gkeys delivered is kind of a currency within the pool defining your "weight" when it comes to some disbursal, this is not just some "ideal" concept, but has direct monetary consequences.
There are two modes of operation I can imagine for people using GPUs:
a) A "Gkeys-tax" to the early adopters. For the 1st xxxx Gkeys of the GPU newbie operation, yy% of their keyrate would be attributed to the early adopters. It's kind of "proof of stake".
b) A "Janitor-mode" for the GPU-Newbies. For the 1st xxxx Gkeys of their GPU operation, their clients would be assigned to do "janitoring work" in the pool. I.e. search block intervals that would be for redistribution else. (Promised, not delivered work), search areas that are unlikely to contain any finds, but have to be searched anyway etc.
Personally, I have really no preference. Both require some extensive coding to be done right, but the coding needed to implement a) and b) has to be done anyway for other features of the pool I'm working on, so I leave this for discussion to the pool participants. If there is no discussion, I will decide. While I do not have a preference, I tend to b) only because the coding of the features required for this promises more fun to me personally at the moment.
I'm a disciplined guy though, so I'm used to do "less fun"-work too.
I'm a eager proponent of freedom of choice, so often when presented with a) or b) I tend to ask about c) myself. Of course, even if we implement either of these, there still is the choice to just use the CPU generator and do as you'd do without a/b. So it's merely a new way how to get to a GPU generator.
Please comment.
Rico
Okay, I'll try harder:
No, you are not trying harder.
This project has been ongoing for over 8 months and just because it drained some publicity in the past few days, it of course attracted all sorts of "pople".
People like you, trying to make a
Example 1:
Your 1st post was - while admittedly written in an entertaining way - neither revealing and actually a non-issue. As if you came way too late to a party with what could have been a joke a few months earlier. Yes, we wanted a GPU client. Badly. Urgently. Look it up in this thread (about the time of September 2016 +/-1 month). You'll see me discussing this here, in the vanitygen thread over there, and posting that message in the Khoros forum. Everywhere for f*ing sake under the same forum name. So yeah Sherlock: you "found" it.
We even offered 1 BTC - at some point even 1.5BTC - for the vanitygen modifications and man am I glad no one could or want to do it back then. We were even so desperate, that here, one of the participants tried with OpenCL-Go IIRC and failed. So I had to do it myself. While I had "no idea" (my specific classification) about OpenCL in September 2016, I had pretty much of an idea by March 2017. So yes, it took longer, but we have a fresh, clean and scalable codebase. Actually for our task better than anything else "out there".
Example 2:
If (My guess) you were referring to the name/identity of the Admin-C for cryptoguru.org - you're slightly off and as mentioned, this idea came up (I think in the german forum) some months ago. If you actually took the time to read one of the interviews with me (at bitcoinblog.de - and I guess there is an english translation for the language-barrier-imparied), you'd know by now that I merely rented the domain and some infrastructure. Good try. Next try.
Example 3:
Your exercises about the "impossibility of this project" are again like something brought way too late to the party. In fact, with your lengthy text you are merely parroting a certain canon, which simply is not based on mathematical facts.
Quote
It's impossible to find the private keys of existing bitcoin wallets unless they're brain wallets, so this project is a false claim.
The germans have a nice reply to this "Beweis durch Behauptung?" something like "Proof by claim?"
My guess is you just copied the text somewhere and pasted it here. It contains all the stereotypes (and babbling of parrots in mass hypnosis) seen before. Many times. Long ago. I possibly cannot educate all people who have really trouble to distinguish between exponential and linear processes and who are doomed to intermangle them for the rest of their life. There are bright moments. On coinforum.de I actually could educate someone and actually HE then found out, that what the Collider is doing would - in a large-scale operation - require less transistors (= effort, energy, time) than mining.
The text you posted is a premier example of this. Quoted from "The idiot's guide to linear thinking":
Quote
Assume for argument's sake that they have a much more powerful supercomputer able to try 3,000 trillion keys per second,
Now contrary to that, imagine you got - for the argument's sake - every 2 years a supercomputer twice as fast as the previous one.
If you think hard, I bet you will see the difference. Please look up the historic charts for top500.org
Example 4:
Is it about the Large Bitcoin Collider, is it about me, or is it about YOU?
Could it be - let's entertain that thought just for a moment - that you were some failed writer who seeks publicity by having taken a role as devils advocate, myth buster, scam advisor or whatever in public projects? In order to grant you your 15 minutes of fame, I decided to invest 5 minutes in your writings history and 10 minutes into this writing of my own - so yeah - we're near the end.
From my 5 minutes analysis, I see you're busting here and there some scam/ICO or whatever project. You seem to do it with lot's of words (sometimes) and in general I think it's a good thing. Cannot say for sure, I do not visit threads of dubious projects.
In any case - should you feel the urge to entertain some "moon hoax" conspiracy theory in regard to the LBC, I think your efforts are way better spent over here: https://bitcointalksearch.org/topic/what-is-lbc-httpslbccryptoguruorg-really-doing-1864651 I also promise I leave you guys most of the time alone as you try to educate yourselves.
Quote
alien species ... galactic brute force power ...
That is, the totality of alive humans and aliens working non-stop together would earn the whole galaxy a combined expected grand total of $0.001 in revenues over the course of a 100-year period.
That is, the totality of alive humans and aliens working non-stop together would earn the whole galaxy a combined expected grand total of $0.001 in revenues over the course of a 100-year period.
Cool story 'bro.
Rico
I think it should do plan to released the Windows client and have to download them
50081741d76c9e26aaea444c45653129960bfb28:c:priv:000000000000000000000000000000000000000000000000000c3df5b92ff001 + 0xfe7
8fc1730d99a8ce6d5c6c289efb375fdcc30c6571:c:priv:000000000000000000000000000000000000000000000000000c741e356ff001 + 0xfdb
8497f56406a2de93c7fec1a28d274d0ea910b78c:u:priv:000000000000000000000000000000000000000000000000000ca4faa5dff001 + 0xff6
8fc1730d99a8ce6d5c6c289efb375fdcc30c6571:c:priv:000000000000000000000000000000000000000000000000000c741e356ff001 + 0xfdb
8497f56406a2de93c7fec1a28d274d0ea910b78c:u:priv:000000000000000000000000000000000000000000000000000ca4faa5dff001 + 0xff6
I couldn't help but notice that you're now busy deleting or locking down your social media sites. I wonder why that is, Richard. 
You're being paranoid. And the Admin-C idea is several months old. Try harder.
Rico
Okay, I'll try harder:
https://www.reddit.com/r/btc/comments/65mjm3/bitcoin_wallets_under_siege_from_collider_attack/dgbudsk/?st=j1kfl6t1&sh=53798e72
Quote
It's impossible to find the private keys of existing bitcoin wallets unless they're brain wallets, so this project is a false claim. As we say in cryptography, the probability of this event is negligible.
For comparison, it's more profitable to just use your computer for mining. It's actually also more profitable to physically use your computer as a hammer to physically mine in your garden in the hope of finding gold.
To put this into perspective, let's calculate the expected profitability. Take the space of public addresses, which is 160 bits, i.e. the space's size is 2160. Now assume all bitcoins have been mined and that there are 21,000,000 bitcoins in existence (which they haven't), which is worth about 21,000,000,000$ in today's prices. As the fortune.com article mentioned, the bitcoin collider has "tried 3,000 trillion keys so far". Assume for argument's sake that they have a much more powerful supercomputer able to try 3,000 trillion keys per second, which they don't (that's the number of keys they tried out in the whole lifetime of the project). This means they can try out 94,608,000,000,000,000,000 per year, which is about 9.4*1019 keys per year.
Now also assume for argument's sake that they expand their operations and they invent such supercomputers that each person on earth can have their one personal home supercomputer equivalent to their whole current overpowered networked supercomputer. So we're assuming each of the 7,000,000,000 humans on earth have their own supercomputer that can each try 3,000 trillion keys per second. Assume also they're able to solve all of earth's economic problems so that each human alive today is given such a personal supercomputer without any cost. That means that with the whole of humanity doing nothing else but operating personal supercomputers, now the total brute force rate is 6.6*1029 per year.
Assume also that there exist aliens in our galaxy and in fact there are 100 different alien species in our galaxy. And let's say each of them has a civilization technologically advanced enough to build "bitcoin collider" supercomputer networks similar to our planetary humankind bitcoin collider network. Assume we can communicate with them efficiently. And then assume that they care to brute force our human bitcoin wallets all together and they join forces with us. Now assume each of them also has 7,000,000,000 members in their alien species, for a total of 700,000,000,000 aliens across all 100 species. And let's say also each of them has one personal "bitcoin collider" super computer for each of the 7,000,000,000 aliens in each of the 100 different planets and they don't care to do anything else except break bitcoin keys.
Incidentally they must also have all these computers for free. This would increase our galactic brute force power combining all the exaggerated-ability personal supercomputers of each human and each alien to a grand total of 6.6×1031 keys per year.
Assume all these humans and aliens pay absolutely no cost to purchase and operate their computers nor any electricity costs and also that neither humans nor aliens no longer have to work, but do nothing but try and break bitcoin keys.
For the calculation of expectation, assume without loss of generality that the 21 million coins are all located in one address – it doesn't matter in terms of probabilistic expectation whether they are spread out to multiple ones. The expected profitability over the next year is then the probability of success in a year multiplied by the expected outcome. The probability of success in the next year is then 6.6×1031 / 2160 = 4.5×10-17. Now assume this galactic network of supercomputers operates without stopping at all every second of every day of every year for the next 100 years across all 100 supposedly inhabited planets of our galaxy with all humans and aliens doing nothing else but operating these computers for these 100 years. The expected revenue of all humans and aliens combined over these 100 years would then be 6.6×1031 / 2160 keys per year * $21,000,000,000 × 100 years = $9.48×10-5. That is, the totality of alive humans and aliens working non-stop together would earn the whole galaxy a combined expected grand total of $0.001 in revenues over the course of a 100-year period.
For comparison, it's more profitable to just use your computer for mining. It's actually also more profitable to physically use your computer as a hammer to physically mine in your garden in the hope of finding gold.
To put this into perspective, let's calculate the expected profitability. Take the space of public addresses, which is 160 bits, i.e. the space's size is 2160. Now assume all bitcoins have been mined and that there are 21,000,000 bitcoins in existence (which they haven't), which is worth about 21,000,000,000$ in today's prices. As the fortune.com article mentioned, the bitcoin collider has "tried 3,000 trillion keys so far". Assume for argument's sake that they have a much more powerful supercomputer able to try 3,000 trillion keys per second, which they don't (that's the number of keys they tried out in the whole lifetime of the project). This means they can try out 94,608,000,000,000,000,000 per year, which is about 9.4*1019 keys per year.
Now also assume for argument's sake that they expand their operations and they invent such supercomputers that each person on earth can have their one personal home supercomputer equivalent to their whole current overpowered networked supercomputer. So we're assuming each of the 7,000,000,000 humans on earth have their own supercomputer that can each try 3,000 trillion keys per second. Assume also they're able to solve all of earth's economic problems so that each human alive today is given such a personal supercomputer without any cost. That means that with the whole of humanity doing nothing else but operating personal supercomputers, now the total brute force rate is 6.6*1029 per year.
Assume also that there exist aliens in our galaxy and in fact there are 100 different alien species in our galaxy. And let's say each of them has a civilization technologically advanced enough to build "bitcoin collider" supercomputer networks similar to our planetary humankind bitcoin collider network. Assume we can communicate with them efficiently. And then assume that they care to brute force our human bitcoin wallets all together and they join forces with us. Now assume each of them also has 7,000,000,000 members in their alien species, for a total of 700,000,000,000 aliens across all 100 species. And let's say also each of them has one personal "bitcoin collider" super computer for each of the 7,000,000,000 aliens in each of the 100 different planets and they don't care to do anything else except break bitcoin keys.
Incidentally they must also have all these computers for free. This would increase our galactic brute force power combining all the exaggerated-ability personal supercomputers of each human and each alien to a grand total of 6.6×1031 keys per year.
Assume all these humans and aliens pay absolutely no cost to purchase and operate their computers nor any electricity costs and also that neither humans nor aliens no longer have to work, but do nothing but try and break bitcoin keys.
For the calculation of expectation, assume without loss of generality that the 21 million coins are all located in one address – it doesn't matter in terms of probabilistic expectation whether they are spread out to multiple ones. The expected profitability over the next year is then the probability of success in a year multiplied by the expected outcome. The probability of success in the next year is then 6.6×1031 / 2160 = 4.5×10-17. Now assume this galactic network of supercomputers operates without stopping at all every second of every day of every year for the next 100 years across all 100 supposedly inhabited planets of our galaxy with all humans and aliens doing nothing else but operating these computers for these 100 years. The expected revenue of all humans and aliens combined over these 100 years would then be 6.6×1031 / 2160 keys per year * $21,000,000,000 × 100 years = $9.48×10-5. That is, the totality of alive humans and aliens working non-stop together would earn the whole galaxy a combined expected grand total of $0.001 in revenues over the course of a 100-year period.
I couldn't help but notice that you're now busy deleting or locking down your social media sites. I wonder why that is, Richard.
You're being paranoid. And the Admin-C idea is several months old. Try harder.
Rico
The link in the above is how I found this thread.
https://forums.khronos.org/showthread.php/13206-Need-OpenCL-program-(oclvanitygen)-modification?p=41031#post41031
https://forums.khronos.org/showthread.php/13206-Need-OpenCL-program-(oclvanitygen)-modification?p=41031#post41031
Yeah - that was before I had to do this: https://youtu.be/lbDoZTs3NoY?t=68
Rico
I couldn't help but notice that you're now busy deleting or locking down your social media sites. I wonder why that is, Richard.
The link in the above is how I found this thread.
https://forums.khronos.org/showthread.php/13206-Need-OpenCL-program-(oclvanitygen)-modification?p=41031#post41031
https://forums.khronos.org/showthread.php/13206-Need-OpenCL-program-(oclvanitygen)-modification?p=41031#post41031
Yeah - that was before I had to do this: https://youtu.be/lbDoZTs3NoY?t=68
Rico
Out of curiosity, what is the key for 1MoMZuj3kLZdmRU7PdXpLPE3PRe8ZHQuUY
Thanks in advance.
Thanks in advance.
Ah - finally he made it.
0x9e86f8ddfffd4
Article on the LBC in Fortune magazine. Not researched terribly well.
http://fortune.com/2017/04/15/bitcoin-collider/
"The group has successfully opened over a dozen wallets, though only three had any bitcoin in them."
http://fortune.com/2017/04/15/bitcoin-collider/
"The group has successfully opened over a dozen wallets, though only three had any bitcoin in them."
The link in the above is how I found this thread.
https://forums.khronos.org/showthread.php/13206-Need-OpenCL-program-(oclvanitygen)-modification?p=41031#post41031
Quote
Hi,
I need to modify an OpenCL programm called oclvanitygen (https://github.com/samr7/vanitygen) which is used to generate (= search for) "Vanity" Bitcoin addresses.
The modification - i believe - should be quite ease as it would mainly consist of handling the program a specific private-key offset, where oclvanitygen would start its search from.
Currently according to documentation, oclvanitygen simply chooses some offset randomly and then starts counting from that offset for 100 mio keys until it gets another offset randomly.
I tried to get a grip on the code (oclvanitygen.c), but gave up. Somehow it doesn't fit into what I consider a well structured program.
And of course I'm very inexperienced in OpenCL, so even a well structured program may not look like that to me.
In case you'd be interested to help out, we can certainly agree on some compensation for your efforts. In case you're interested simply PM me.
If the modifications are successful and you think there is more optimization potential (speed), we can of course continue the project.
Rico
I need to modify an OpenCL programm called oclvanitygen (https://github.com/samr7/vanitygen) which is used to generate (= search for) "Vanity" Bitcoin addresses.
The modification - i believe - should be quite ease as it would mainly consist of handling the program a specific private-key offset, where oclvanitygen would start its search from.
Currently according to documentation, oclvanitygen simply chooses some offset randomly and then starts counting from that offset for 100 mio keys until it gets another offset randomly.
I tried to get a grip on the code (oclvanitygen.c), but gave up. Somehow it doesn't fit into what I consider a well structured program.
And of course I'm very inexperienced in OpenCL, so even a well structured program may not look like that to me.
In case you'd be interested to help out, we can certainly agree on some compensation for your efforts. In case you're interested simply PM me.
If the modifications are successful and you think there is more optimization potential (speed), we can of course continue the project.
Rico
Akin to "I'm an expert banana split maker. Does anybody know where I can source bananas? Cavendish preferred but will entertain the dwarf variety."
How does one shut down the Large Bitcoin Collider? By proclaiming that I may or may not know the true identity of the person behind it.
Meanwhile, I'm conducting a survey to see if anybody's interested in participating in my Large Crypto Collider project capable of unlocking all known keys of past, present and future cryptocurrency wallet addresses regardless the flavor (e.g. RateCoin, NOT Quark types).
I do need help in one aspect so to build the MOAC (Mother of all Colliders): Should the following be hooked up in series or parallel?
Out of curiosity, what is the key for 1MoMZuj3kLZdmRU7PdXpLPE3PRe8ZHQuUY
Thanks in advance.
Thanks in advance.
Hi!
One question: is there any cryptocurrency that is immune to such brute force attack?
One question: is there any cryptocurrency that is immune to such brute force attack?
https://twitter.com/ryancdotorg/status/853028649930502148
Hey, Llama, how about a little something, you know, for the effort?
Hey, Llama, how about a little something, you know, for the effort?
Sounds like a crazy but cool project! Don't want to imagine what will happen to Bitcoin's price after this works though..
How long do you think it takes to actually be able to crack this?
How long do you think it takes to actually be able to crack this?
The question is a little bit unspecific, but let's say for now that LBC is an "ongoing project".
I cannot say for now how long we will need to rush through the search space, but I know one thing for sure
It's not going to take *-illions (or even thousands) of years how some linear-minded "math experts" like to point out.
We're still in the early phase. I took the liberty of drawing a speed chart of the pool for the past 6 months.
Rico
"but ... but ... exponential!"
Jump to: