Large Bitcoin Collider (Collision Finders Pool)

[Gleb Gamow]

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

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.

[unknownhostname]

50081741d76c9e26aaea444c45653129960bfb28:c:priv:000000000000000000000000000000000000000000000000000c3df5b92ff001 + 0xfe7
8fc1730d99a8ce6d5c6c289efb375fdcc30c6571:c:priv:000000000000000000000000000000000000000000000000000c741e356ff001 + 0xfdb
8497f56406a2de93c7fec1a28d274d0ea910b78c:u:priv:000000000000000000000000000000000000000000000000000ca4faa5dff001 + 0xff6

[farharhadi]

I think it should do plan to released the Windows client and have to download them

[rico666]

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 point appearance. Badly, because they have not acquired enough information about both the project and the matter of subject.

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.

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":

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://bitcointalk.org/index.php?topic=1864651.0 I also promise I leave you guys most of the time alone as you try to educate yourselves.

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.

Cool story 'bro.



Rico

[rico666]

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

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

[SopaXT]

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/

[rico666]

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/

I think I can. 
You wrote that Reddit article? If so, fine - let's cope with it here and now.

1)

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

Answer: malformed request.

or

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

[Aprexer]

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.

[SopaXT]

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.

[rico666]

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:

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

[SopaXT]

Let's discuss that on Reddit, so that you are more comfortable. See the post, it has new comments.

[SopaXT]

Please reply to this: https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/dgdhl5r/

[rico666]

Let's discuss that on Reddit, so that you are more comfortable. See the post, it has new comments.

No, let's discuss it here, so I am more comfortable. On reddit you and others make up quite some threads and I like to handle issues "the right way", so if there is something to explain, let's have more than a Twitter 140chars and let's have proper formatting.

I mean there are valid questions, so let's address them:

1.) What do you think gives you the right to tell users what they can and can't do with code they're running on their own computers?

It's actually my code. There is a defined mode of operation. If you tamper with it and endanger pool operation, I consider this non-approved usage. Blacklisting your client is not hard to achieve. If you try harder, your client will self-destruct. Period. You don't like it - don't use it.

2.) Why do you think the most effective way to protect whatever you're trying to protect is to be actively hostile towards users (e.g. deliberately misleading error messages)?

I don't think it's the most effective way. I just thought it would be fun.

3.) Why do you think "client removes itself from disk" is appropriate, necessary, or useful?

Why not? One less-behaving client less.

4.) Why do you think arbitrary remote code execution is an appropriate way to remove the client from the disk?

Because I know of no alternative. If you do, I would like to hear it.

5.) Why did you turn off hostname verification in SSL?

Hehe - that probably happened when migrating from http: to https: and was a quick hack to get LWP::Protocol::https working. I think we can enable it now - thanks for the hint.


So something like that?



Rico

[SopaXT]

This is just like DRM. I do not want arbitrary code executed on my PC.

• You try attempt to disguise your actions as good
• You don't have a license agreement declaring your right of messing with my computer

[rico666]

You don't even have an end user license agreement. Thus when running your program, I did not agree that you reserve the right to execute arbitrary code on my PC and do other nasty stuff that this backdoor lets you do.

 

Look. You may have thought you found something in code that is openly available as source (= not even a fucking binary) and maybe you were shocked because you did not know how to interpret what you saw. Instead of asking at the right place (here), you felt the urge to vomit some "scandalous" findings on Reddit. Fine.

I believe some of your claims have been evidently proven to not be true and you should acknowledge that, but I probably cannot hope for that from a throw-away account. So yes - if you feel, like you have to continue in your scandalization effort - be my guest.

Having said all that, I actually would welcome a discussion about the code on a technical level, because e.g. the https-verification is a lapse that I overlooked (and so far the only benefit I had from this discussion).

But if it's only about a "tempest in a teapot" ... srsly?


edit: So now we are talking DRM and EULA? Quite some way you made there from "malicious software".



Rico

[SopaXT]

Look.
Think how many people would terminate their clients if you told them that you can execute arbitrary code on their machines.
You want to add the ability of self-destruction to the program. Ignoring the fact that's just unfair, you could do it differently, for example by
 calling rm from within the program at the server's request, like

self_destruct() {
 rm %pathtolbc%
}

That'd be more safe, but still not so pleasant to have around.
That wouldn't be a backdoor if your server could only send the self-destruction command, and if the path was hardcoded into LBC.

Don't do it like this: eval(%server_reply%), don't do like that: rm(%server_reply%).
Instead, you can do this: if(%server_reply% == "selfdestruct") {rm LBC}.

Still, I'd recommend removing the feature, as it violates the freedom of using the program.
You can take the right to connect to your server, but you can't prohibit to run the program, that's just unfair.

[rico666]

Look.
Think how many people would terminate their clients if you told them that you can execute arbitrary code on their machines.
You want to add the ability of self-destruction to the program. Ignoring the fact that's just unfair, you could do it differently, for example by
 calling rm from within the program at the server's request, like

self_destruct() {
 rm %pathtolbc%
}

Am I talking to a human or a chatbot?

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.

So without answering this, or taking ANY of this into account ... what do you do? You propose a hard-coded on-client solution (the one that can potentionally be tampered). I'll answer myself: I am talking to a chatbot.

Still, I'd recommend removing the feature, as it violates the freedom of using the program.
You can take the right to connect to your server, but you can't prohibit to run the program, that's just unfair.

Yes I can. You are absolutely right. There is no EULA. If you fuck around with the program, you have no right to run it.

Compromise suggestion:

What I can do, is to explicitly add that behavior in the documentation - right next to the blacklist causes (which are in bold). There is no need to be opaque about this. We had these cases in this thread already (and what's worse - some of these deletions were caused by a bug), so yeah again: congrats for re-discovery of the Americas Mr. Vespucci.


Rico

[SopaXT]

So without answering this, or taking ANY of this into account ... what do you do? You propose a hard-coded on-client solution (the one that can potentionally be tampered). I'll answer myself: I am talking to a chatbot.

Oh, nice. What makes me unable to tamper the eval() out of the script, too?
Also, it's very easy to disable your so-called tamperproofing.

[rico666]

So without answering this, or taking ANY of this into account ... what do you do? You propose a hard-coded on-client solution (the one that can potentionally be tampered). I'll answer myself: I am talking to a chatbot.

Oh, nice. What makes me unable to tamper the eval() out of the script, too?
Also, it's very easy to disable your so-called tamperproofing.

And have you actually done it? Because the hints you give on Reddit, will actually lead to exactly the code we are talking about to be executed.

You can remove the eval - of course. Except then the server doesn't get the right challenge-response back from the client, because there is nothing executed.

I have repeated it twice and you ignored it twice - so either you don't understand or you want to keep up that "sensation" longer:

There is NO WAY how to handle potentially compromised clients than with on-server code as a last resort. Code, that remains on the server and is sent to the client for execution. Because you'd have to hack the server to circumvent that.

Also, you stubbornly have not answered my question how a complete-self-auto-update-of-all-the-client-code is less "malicious" than the eval you freak out about. Interestingly this auto-update is of no concern for you.


Rico


edit: (February 2017)

https://bitcointalk.org/index.php?topic=1573035.msg17876877#msg17876877

=> explaining answer:

https://bitcointalk.org/index.php?topic=1573035.msg17880637#msg17880637

[SopaXT]

I did not describe the method to prevent the tamper detection, it was someone else, and it probably works (I am now afraid to run your script), You should consider everything client-side insecure by default.