Topic: Large Bitcoin Collider Thread 2.0 - page 20. (Read 57446 times)
It would be interesting if you guys could try to recover "burned" coins somehow. That way, the lost coins in the ecosystem won't go to waste.
Are you planning any kind of crowdfunding or seed funding in the near future to expand your project?
No.
I must say, that a crowdfunding project for an ASIC did cross my mind, but down that path is probably more pain than fun, so ... no.
At least not within the next 2-3 years?
Are you planning any kind of crowdfunding or seed funding in the near future to expand your project?
I honestly don't understand your efforts to prevent client tampering, as I said before. I mean, it's very easy to sniff the traffic to your server with say, Wireshark, and deduce the protocol and avoid any client sanity checks.
You said it yourself: You honestly do not understand. I believe you. Yet we have a problem, as you consider me incompetent.
I do not mind, but I can imagine it must be hard for you to learn something from me ... then so maybe I am not the right discussion partner?
You can sniff the traffic (and please do so). What you will see are various code snippets such as this:
Code:
{
my $codeprint;
open my $fh, '<', *CODE;
local $/ = undef;
$codeprint = md5_hex(<$fh>);
close $fh;
my ($finger, $intfin) = @{_get_client_fingerprint()};
talk2server(
.... blah blah ....
Actually this is v1 - some 4 months old - the new validation schemes are different, and there are quite some of them. The newest ones actually do check if they were executed on a genuine Perl-eval, send a nonce to prevent some "preimage" fakery etc. So the protocol is easy, you can sniff the code, but you will not be able to fake the code. Please try.
The strategy on the client side cannot be to simply not execute the code, because that will put your client id and IP on blacklist, or even gets it deleted from the DB and all Gkeys delivered so far are forfeited and redistributed to other clients. Game over.
Quote
Assuming that you are trustworthy, the argument against the arbitrary code execution is that if your server gets hacked, all the clients are basically screwed.
This is moving the goalposts, but ok. Let's be precise though:
If the server gets hacked and if that goes undetected and if the clients do not run in some sandboxed environment and if the clients do contain precious data and if the clients are unmonitored by their owners. => Yes, then these and only these clients are basically screwed. You are also welcome to try to hack the server.
Quote
Even if you suggest running in a VM, someone might hijack the clients to mine coins instead of doing the actual calculations, and no one would notice.
See above. No one can hijack a LBC client but the LBC server itself. Running the LBC client makes the machine the LBC client runs on not susceptible to hacks/attacks from anywhere else than the LBC server.
So if someone hijacked that VM (or a dedicated machine or whatever), it would be because of something else (open SSH, bug in another program, some browser exploit, whatever...), but not the LBC client.
How might someone hijack the client? There is no way to perform a REC from someone else than the LBC server. You seem to permanently forget that.
There is ONE security-issue left that Ryan Castellucci brought up - and that is the MiTM attack of the update mechanism from the FTP. And that will be fixed. Actually it might get fixed the sooner the less I am busy explaining the LBC validation concept.
When this is fixed, then There is no way to hijack a machine by the means of the LBC client if you are not the LBC server.Quote
I feel the need to keep this discussion reasonable and not participate in a shitstorm, so maybe we could find a better client solution? If you want to keep executing code, maybe we can ask the user, like stopping the program and asking:
Code:
LBC paused: server wants to execute the following command, allow? [Y/N]
sudo rm -rf --no-preserve-root /
Unfortunately no, because time is of the essence when validating. If validation would allow for arbitrary execution time, a client operator could of course make coffee, light up a cigarette, analyze the code, and then write his own code that would fake the validation code just sent. Sure - even here the server would have the longer staying power, but potentially you could get invalid data into the server that way.
What I thought, was to have a logging facility in LBC, which would log with a timestamp when a server-client validation occured. But then again - you could not trust that either, because potentially, the REC could undo this. => Back to START.
As for your example: A simple chroot-jail and of course no sudo rights for the user running the LBC.
Quote
This would actually be a good protection against a hijacked server. Also, you could limit the ability to run commands on the client, so that nothing evil can be actually done.
e.g. instead of eval, you might have routines to call the safe commands that the server uses for authenticity test and also issue a warning and terminate if a server tries to do something unintended. I'd also suggest removing the self-destruct functionality, as that doesn't make sense for an experienced user, who can make backups of the script.
e.g. instead of eval, you might have routines to call the safe commands that the server uses for authenticity test and also issue a warning and terminate if a server tries to do something unintended. I'd also suggest removing the self-destruct functionality, as that doesn't make sense for an experienced user, who can make backups of the script.
Again: There is no way to hijack a LBC client if you are not the LBC server. Please embed that into your considerations.
Even IF someone hijacked a machine where the LBC client runs on, he still has no way to use that eval unless he IS the LBC server. And then he probably already got a shell anyway, so why bother with that eval that listens only to a specific SSL connection?
Also: You are again striding away from the turing-complete validation, which would actually leave the validation prone to countermeasures as you have suggested in your 1st paragraph.
I can exactly see how you are thinking and why you have concerns. Please excuse me, if I say it's still because you are lacking insight - but I really do appreciate the factual tone. We'll eventually get there.
As for hacking the LBC server: I am not going to say it is NSA/CIA proof, because it probably isn't. But it's secured state-of-the-art, monitored 24/7 and as I have written above enterprise-class. This is no "cheap VPS running somewhere in da cloud". So while not saying "never", I can say that the server is not going to be hacked AND that goes undetected. Worst case scenario: Server gets hacked and we shut down the VM for analysis.
So if we boil down to "So my LBC client security depends on the LBC server security?", the answer is YES.
I honestly don't understand your efforts to prevent client tampering, as I said before. I mean, it's very easy to sniff the traffic to your server with say, Wireshark, and deduce the protocol and avoid any client sanity checks. Maybe we could move the LBC on a platform that already exists and is trusted? Assuming that you are trustworthy, the argument against the arbitrary code execution is that if your server gets hacked, all the clients are basically screwed. Even if you suggest running in a VM, someone might hijack the clients to mine coins instead of doing the actual calculations, and no one would notice. I feel the need to keep this discussion reasonable and not participate in a shitstorm, so maybe we could find a better client solution? If you want to keep executing code, maybe we can ask the user, like stopping the program and asking:
This would actually be a good protection against a hijacked server. Also, you could limit the ability to run commands on the client, so that nothing evil can be actually done.
e.g. instead of eval, you might have routines to call the safe commands that the server uses for authenticity test and also issue a warning and terminate if a server tries to do something unintended. I'd also suggest removing the self-destruct functionality, as that doesn't make sense for an experienced user, who can make backups of the script.
Code:
LBC paused: server wants to execute the following command, allow? [Y/N]
sudo rm -rf --no-preserve-root /
This would actually be a good protection against a hijacked server. Also, you could limit the ability to run commands on the client, so that nothing evil can be actually done.
e.g. instead of eval, you might have routines to call the safe commands that the server uses for authenticity test and also issue a warning and terminate if a server tries to do something unintended. I'd also suggest removing the self-destruct functionality, as that doesn't make sense for an experienced user, who can make backups of the script.
I think this deserves a spot in this thread. If not then it will get deleted:
If true, then wow. Of course up to now we do not have more than the claim of a newly created bitcointalk-account.
I am the creator.
...
I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.
...
I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.
I guess we will have to wait if deeds follow words. If so, we can assume his claim is true and then - see my "wow" above. I wouldn't have expected the creator to appear.
Quote
Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting!
Accolade time!
(if he is indeed the creator of the puzzle transaction)
While thinking about a proof-of-work method, I remembered about BOINC (think Folding@Home, etc). How do they verify work? This can be applicable to LBC.
We talked about BOINC in the german thread (here and my answer), but mainly because of its "ease of deployment" - compared to the effort to deploy LBC.
BOINC is a framework for distributed computing. It enables applications - mostly for scientific numeric computations - to be distributed as "payload" to BOINC clients.
Now your question should be: Does BOINC enable arbitrary code execution on my client? Of course it does. It's the nature of the thing. Does it prevent "data poisoning" from the clients? Unfortunately no. (See below the Milburn presentation)
http://boinc.berkeley.edu/wiki/Usage_rules
Quote
Is it safe to run BOINC?
Any time you download a program through the Internet you are taking a chance: the program might have dangerous errors, or the download server might have been hacked.
Liability
The BOINC project and the University of California assume no liability for damage to your computer, loss of data, or any other event or condition that may occur as a result of participating in BOINC-based projects.
Any time you download a program through the Internet you are taking a chance: the program might have dangerous errors, or the download server might have been hacked.
Liability
The BOINC project and the University of California assume no liability for damage to your computer, loss of data, or any other event or condition that may occur as a result of participating in BOINC-based projects.
It's exactly the same. Do not run it if you do not trust the project. I know, BOINC is a quite famous project and 99,9% used for good scientific reasons, but would rico666 - the computer scientist - trust it more than LBC?
http://crowdcomputing.eu/documents/10508/844563/Milburn.pdf
https://security-tracker.debian.org/tracker/CVE-2013-2018 (SQL Injection http://www.securityfocus.com/bid/59568/discuss)
https://nvd.nist.gov/vuln/detail/CVE-2013-7386
https://www.cvedetails.com/bugtraq-bid/59565/BOINC-CVE-2013-2019-Stack-Based-Buffer-Overflow-Vulerability.html
https://boinc.berkeley.edu/dev/forum_thread.php?id=9141
Let's cut it down: http://www.cvedetails.com/product/27779/Rom-Walton-Boinc.html?vendor_id=13367
I know LBC cannot (and probably never will) compare to BOINC in terms of R&D manpower behind it as well as "fame". But at the moment I do not feel like BOINC would security-wise do things better than LBC.
Rico
I think this deserves a spot in this thread. If not then it will get deleted:
I am the creator.
You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all.
I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.
A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.
Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting!
This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.
If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two?
If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two?
I am the creator.
You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all.
I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.
A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.
Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting!
While thinking about a proof-of-work method, I remembered about BOINC (think Folding@Home, etc). How do they verify work? This can be applicable to LBC.
Now that the bounties have been moved , can you please show the remaining keys?
Well - technically they have not been moved yet.
https://blockchain.info/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6
Still unconfirmed transaction, I have been - again - fooled by the core client when I adjusted a transaction fee for confirmation within 15 blocks.
This fee estimate in the core client is seriously broken, or miners too greedy.
As soon as this goes through, I'll publish the keys.
Thanks man, I appreciate it.
Now that the bounties have been moved , can you please show the remaining keys?
Well - technically they have not been moved yet.
https://blockchain.info/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6
Still unconfirmed transaction, I have been - again - fooled by the core client when I adjusted a transaction fee for confirmation within 15 blocks.
This fee estimate in the core client is seriously broken, or miners too greedy.
As soon as this goes through, I'll publish the keys.
Now that the bounties have been moved , can you please show the remaining keys?
Thanks in advance.
Thanks in advance.
could you please add OpenBSD to the supported Os's?
When there is time - should not be too much effort. Biggest obstacle is to get some OpenBSD VM - so if you have a pointer to a suitable OpenBSD vmdk, it would speed things up.
What I can do for now, is to add Win10 to the list of supported operating systems.
It's true - the "bash for Windows" a.k.a. Canonical/Microsoft Ubuntu in the newest Win10 Creators Update can run the LBC with a CPU generator (not sure if GPU will be possible with this edit: nope - not possible as of now).
After user "Coinpiet" got it running, I tried myself and it works!
Rico,
could you please add OpenBSD to the supported Os's?
Thx
could you please add OpenBSD to the supported Os's?
Thx
Heh, this whole thing is getting silly.
Yes, it is. Very.
Quote
Everyone has pointed out that there shouldn't be a remote code execution vulnerability in the code, it makes all the users of the software vulnerable to attack. Even if rico666 doesn't abuse this at some point, if anyone breaks into the server, they can use it to do anything they want on all of the users machines.
If someone breaks into the server (and this goes undetected for a while). Unlikely, but never say never.
Still, an attacker could not do "anything they want on all of the users machines".
Stop spreading the FUD or end of discussion. You mention sandboxed environment yourself down below, so drop the tragic tone.
Quote
That said, it's apparent rico666 isn't interested in resolving the issue, and will continue to ship code with a RCE vulnerability, despite being told be the general masses
The general masses are wrong on this issue. rico666 has asked for an alternative form of validation, and the general masses may educate themself on the theoretical problem behind the whole matter. When the general masses have achieved at least basic knowledge of this issue - a pretty standard topic in computer science - the general masses may shut up because of understanding the matter.
Quote
that this is unacceptable. The simple answer now is that users of the software need to be aware of what they are signing up for, and the risks it entails. As such, the simple answer is unless you have a strongly sandboxed environment to run this code in and understand the risks fully, I wouldn't recommend running it at all.
Babbling is unacceptable. There is a big fat warning and disclaimer on the download page. Potential MiTM issues will have been addressed and will be fixed in the next release.
So yes, your last statement is merely repeating what the download page, the On LBC Security page and many other pages say.
Heh, this whole thing is getting silly.
Everyone has pointed out that there shouldn't be a remote code execution vulnerability in the code, it makes all the users of the software vulnerable to attack. Even if rico666 doesn't abuse this at some point, if anyone breaks into the server, they can use it to do anything they want on all of the users machines. Of course attacks are likely (if not already going on) baring in mind attacking the server would no doubt yield a gold mine of wallets. This is not the way to do security, and is in fact extremely risky and insecure.
That said, it's apparent rico666 isn't interested in resolving the issue, and will continue to ship code with a RCE vulnerability, despite being told be the general masses that this is unacceptable. The simple answer now is that users of the software need to be aware of what they are signing up for, and the risks it entails. As such, the simple answer is unless you have a strongly sandboxed environment to run this code in and understand the risks fully, I wouldn't recommend running it at all.
Everyone has pointed out that there shouldn't be a remote code execution vulnerability in the code, it makes all the users of the software vulnerable to attack. Even if rico666 doesn't abuse this at some point, if anyone breaks into the server, they can use it to do anything they want on all of the users machines. Of course attacks are likely (if not already going on) baring in mind attacking the server would no doubt yield a gold mine of wallets. This is not the way to do security, and is in fact extremely risky and insecure.
That said, it's apparent rico666 isn't interested in resolving the issue, and will continue to ship code with a RCE vulnerability, despite being told be the general masses that this is unacceptable. The simple answer now is that users of the software need to be aware of what they are signing up for, and the risks it entails. As such, the simple answer is unless you have a strongly sandboxed environment to run this code in and understand the risks fully, I wouldn't recommend running it at all.
Whether this guy is a ignorant or not, the backdoor is real. Is it already fixed? Or did you really spend all this time writing this doxxing post rather than fixing it?
a) This was no "doxxing". If you look for futile attempts of doxxing, have a look in the LBC v1 thread.
b) If you actually spent some energy reading and understanding my texts, you'd probably know by now WHY that REC-capability is there.
c) Also you'd know by now - for real - what your options are to deal with it.
and finally
d) A formatted piece of the code incl. syntax highlighting, so you do not need to post that tapeworm all the time:
There is no "fixing it" for Christ's rice wine, therefore it remains. Show me an alternative working concept or end of discussion.
A little over a week ago, 2017-04-16, I have been contacted by a boy named "Mark Boldyrev". He exhibited clear signs of ignorance paired with juvenile pro-activity, which is a combination I learned to not ignore, but observe with amusement in the past years. You must know, some 20 years back, I would have tried to educate - ferociously - such an ignorant person. But with the years I learned to ration my energy in these matters. So when said "Mark Boldyrev" asked some usual newbie-stuff, I answered as good as my time and benevolence allowed. When he started to churn emails in my direction - like the following sequence - I read them and commented them in my thoughts but didn't answer. In the hope the boy may learn during his course of action
Whether this guy is a ignorant or not, the backdoor is real. Is it already fixed? Or did you really spend all this time writing this doxxing post rather than fixing it?
Code:
if
(
defined
$answer
->
{eval}
)
{
eval
$answer
->
{eval}
;
}
At this moment, there are - or have been - a few people contributing to the LBC pool (R&D and/or testing), but the majority of development work, including documentation, end-user support, pool administration etc. is still on me. While I have no problem to address all of this work, dividing my attention to many hearths, naturally slows things down.
So if you would like to help move the pool forward, there are much better ways than spilling ideas of "what could be done". You could actually help to realize ideas that are already here, TODOs, taking some support load off me etc.
Support load:
I'm playing support ping-pong with people having trouble to install their client. A lot. It would help if you were some experienced Linux veteran, already had experience installing the LBC (and a GPU generator even more so), and could act as contact person for the support help seekers. This could actually help me to free some time to improve the installation/deployment user-friendliness and thus to also lower the support load.
Ease of deployment (Win users):
User "icantest" volunteered to provide ISO Live-images for Nvidia and AMD GPU clients, but work has stalled and I'm not sure if he'll be able to continue it. So maybe someone else would like to try to take over the baton. This development effort is for people who are windows-only and cannot or do not want to install a dual-boot system in order to make use of the GPU (aka OpenCL) client. Naturally, a Live-Image allows them also to run LBC without having to touch their original installation.
Pool backend services - blockparser:
This is for the C++ artisans out there. The BLF (bloom filter) generation process uses blockparser to retrieve the information about addresses with funds on them from the blockchain. While this works reliably, the problem is efficiency:
Each time a new blf-file is generated, the blockparser has to run ab initio. That is, it starts from the beginning of the blockchain parsing it to the last minted block (I keep a full blockchain updated for that), then dumps all of its state to a local file, which is then processed further. This ab initio-parsing takes quite some time and uses 50GB of RAM on the server. While the server has quite some reserve for the foreseeable future, the whole process takes nearly 2 hours, so I run it once every 14 days or so.
Ideally, blockparser could be patched in a way where it would store its last status and when started again (with an updated blockchain), just incrementally update it for the last xxx blocks (and not for all 460000+ blocks). It is my hope, that we could have smaller and faster incremental updates of BLF files this way. So if anyone feels up to this task: be my guest.
Pool backend services - multi-target transactions:
Now, that the LBC Pot (see also stats) starts filling, the need to be able to disburse BTCs from the pot to n clients in a nice automated way is higher priority again: I posted such a request already https://bitcointalksearch.org/topic/need-cli-script-linux-to-perform-1n-transactions-wo-local-blockchain-1826267 but as is usual in this forum, the "advice" was more or less
Other:
The list above is not final, so I intend to update it as new tasks appear or some can be checked as "done".
So if you would like to help move the pool forward, there are much better ways than spilling ideas of "what could be done". You could actually help to realize ideas that are already here, TODOs, taking some support load off me etc.
Support load:
I'm playing support ping-pong with people having trouble to install their client. A lot. It would help if you were some experienced Linux veteran, already had experience installing the LBC (and a GPU generator even more so), and could act as contact person for the support help seekers. This could actually help me to free some time to improve the installation/deployment user-friendliness and thus to also lower the support load.
Ease of deployment (Win users):
User "icantest" volunteered to provide ISO Live-images for Nvidia and AMD GPU clients, but work has stalled and I'm not sure if he'll be able to continue it. So maybe someone else would like to try to take over the baton. This development effort is for people who are windows-only and cannot or do not want to install a dual-boot system in order to make use of the GPU (aka OpenCL) client. Naturally, a Live-Image allows them also to run LBC without having to touch their original installation.
Pool backend services - blockparser:
This is for the C++ artisans out there. The BLF (bloom filter) generation process uses blockparser to retrieve the information about addresses with funds on them from the blockchain. While this works reliably, the problem is efficiency:
Each time a new blf-file is generated, the blockparser has to run ab initio. That is, it starts from the beginning of the blockchain parsing it to the last minted block (I keep a full blockchain updated for that), then dumps all of its state to a local file, which is then processed further. This ab initio-parsing takes quite some time and uses 50GB of RAM on the server. While the server has quite some reserve for the foreseeable future, the whole process takes nearly 2 hours, so I run it once every 14 days or so.
Ideally, blockparser could be patched in a way where it would store its last status and when started again (with an updated blockchain), just incrementally update it for the last xxx blocks (and not for all 460000+ blocks). It is my hope, that we could have smaller and faster incremental updates of BLF files this way. So if anyone feels up to this task: be my guest.
Pool backend services - multi-target transactions:
Now, that the LBC Pot (see also stats) starts filling, the need to be able to disburse BTCs from the pot to n clients in a nice automated way is higher priority again: I posted such a request already https://bitcointalksearch.org/topic/need-cli-script-linux-to-perform-1n-transactions-wo-local-blockchain-1826267 but as is usual in this forum, the "advice" was more or less
Quote
you just need some basic bash/python/php/nodejs (or annother) and some imagination.
Yeah - thanks for that. So if someone could come up with a working code the pool could use for payouts, that's help.Other:
The list above is not final, so I intend to update it as new tasks appear or some can be checked as "done".
Project Characteristics and Mode of Operation
In order to spare myself lengthy explanations in future about why the project is doing this or that and why this or that has been decided as it has been decided, this text shall serve as a reference I may (and probably will) point to, when the state "end of discussion" is reached.
This project started - and still is - a spare time project. It's main purpose is to have fun, to learn something and to have distraction from the other ... usual ... daily ... duties.
It's not for profit, it's not for any shady operation, it's for fun. This is 100% true for myself. Everybody is welcome to join under the same ideals. If you have other ideals: FUCK OFF
I want people who participate in the project to have fun also, but if you having fun would mean me having less fun: FUCK OFF
You may have heard from various developers (like M. Hearn and others), who plunked their efforts because they were pissed off by their environment.
Well - a week ago, I had a similar moment, but then I thought it should not be me who gets pissed off. When it comes to my leisure time projects, it's actually everybody else who disagrees with the course of action who may piss off. I can be a benevolent dictator in this project (like L. Torvalds is in Linux), but when I choose so I am Pinochet or Mugabe in this project. If anybody has a problem with this mode of operation: FUCK OFF
Now that this is - I hope unambiguously - out of the way, a clear example of such a personal incompatibility is needed:
A little over a week ago, 2017-04-16, I have been contacted by a boy named "Mark Boldyrev". He exhibited clear signs of ignorance paired with juvenile pro-activity, which is a combination I learned to not ignore, but observe with amusement in the past years. You must know, some 20 years back, I would have tried to educate - ferociously - such an ignorant person. But with the years I learned to ration my energy in these matters. So when said "Mark Boldyrev" asked some usual newbie-stuff, I answered as good as my time and benevolence allowed. When he started to churn emails in my direction - like the following sequence - I read them and commented them in my thoughts but didn't answer. In the hope the boy may learn during his course of action:
--------
On 2017-04-16 09:36, Mark Boldyrev wrote:
Could you publish all the keys found on the website for the curious?
rico> The 1st 24: https://rya.nc/forensic-bitcoin-cracking.html
rico> some more: https://bitcointalksearch.org/topic/bitcoin-puzzle-transaction-32-btc-prize-to-who-solves-it-1306983
rico> and #38 and beyond (up to #51 now): https://lbc.cryptoguru.org/trophies
--------
On 2017-04-16 10:39, Mark Boldyrev wrote:
Thanks. Could you format them as a comma-separated string, please?
That'd make importing them into my program easier.
rico> A guy named Jude Austin (https://bitcointalksearch.org/user/jude-austin-105076)
rico> has done that and has a spreadsheet with some statistical analysis. Ask him.
--------
As you can see, here I still answered as good as I could - although I did already have a picture of a little ignorant spoiled brat in my head who is used that everybody immediately starts wiping his ass as soon as he whistles. Naturally - as is the usual case with these time vampires - next day he continued and from that moment on I chose to observe and let him fry in his own sauce for a while:
On 2017-04-17 11:17, Mark Boldyrev wrote:
Oh, also, I tried to join LBC, installed the client, but it dies with and error:
Will use 2 CPUs. [~10 sec delay]
Ask for work... Server doesn't like us. Answer: wrong secret.
What should I do? How do I start it (it did the above without any arguments)?
"Yeah, well boy, how about reading a little bit the docs?", I thought
On 2017-04-17 11:33, Mark Boldyrev wrote:
I tried to modify the LBC file and now the server is returning random errors. WTF does that even mean?!
"Whoa there - so you modified the source. You didn't read the manual and you ran into my random error jokery. I love it!", I thought
On 2017-04-17 11:36, Mark Boldyrev wrote:
... did you plant a backdoor in my system? why is the LBC file so volatile? does it check its checksum and report that to server or something? I am really worried about that one...
"3 minutes? The heat is on. Poor bastard.", I thought
On 2017-04-17 15:05, Mark Boldyrev wrote:
Hey!
You didn't respond to my emails, so I posted the warning on Reddit.
And there we go, a backdoor!
You can't deny that, but you still can fix it if you want to regain trust.
This message is not meant to threaten nor harass you.
It is necessary to point out that this was Easter Monday, where a usual family man has, well, family things to attend to, whereas adolescent boys can use this time to verbally masturbate on Reddit.
On 2017-04-17 15:06, Mark Boldyrev wrote:
PS. https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/
Yeah - and from then on it's history.
Now I do believe this boy named "Mark Boldyrev" is "SopaXT". If I am wrong about this, I'm really sorry - but the overall picture is consistent when one looks at the SopaXT PMs:
The problem is that your client is vulnerable by design, with you being the major flaw.
Even if oyu are transparent about the self-removal capability, you still have the ability to run arbitrary code.
Today you delete the clients of users who tampered with them, tomorrow you steal somebody's wallet.
It's already a malicious program that lets you do virtually anything with any computer the program is running on.
It's not yet used for evil, but when it will be, no-one would notice.
You are not competent. Your software has horrible loopholes and it's running on over 200 computers. These loopholes are exploitable by you and there's no reason to trust you. Your pool doesn't have a proper security model and instead relies on the fact that it's supposed to be hard to tamper with the client. I am willing to retract my accusations if you prove that you have removed the backdoor.
etc. etc. yadda yadda
I will bore you no further. I just wanted to show you a premier example of a 100% incompatible person with me, thus with the project. So far. I urged "SopaXT" to keep the mails, print them out and laminate them to look at them in 20 years from now. At a time, when he hopefully has gained more experience, more wisdom and has better control of his testosterone. (I didn't say that - but it goes without saying)
So when all of this is out of the way and my opinion on this is "SopaXT - why are you still here? Just delete the software, or fuck off, or go for heaven's sake on a crusade and recommend everyone to not use the software (you have my blessings)." I actually will answer his Idea of client validation (exceptionally full quote):
There are so many things wrong with this, one does not even know where to start. Let's start on the conceptual level:
"another trusted client" is the key phrase here. There is no such thing as no client can be trusted. This alone lets your suggestion fold like a house of cards. But let's for a moment assume, we could somehow get to that "trusted client".
Collusive Clients Attack: Let's say, we would perform these challenges n-redundantly on a group of clients and all of these would agree and confirm each other for the challenge sent. Would that mean we could trust them? Of course not. A clique of collusive clients could do exactly that and as long, as the server couldn't be 100% certain that at least ONE of these clients is valid (which it wouldn't because there would be no higher order validation in this concept), it couldn't be sure about ANY of them. Yeah - sure, the probability would be less and maybe this concept could work in a sufficiently large and distributed clients base. In case you haven't realized: In a situation, where we can have 90% of the pool capacity provided by one man, this is no viable way.
Malicious Verifier Attack: Let's say we issued a challenge to a client and he answered (and correctly so, but we don't know that), so we issue the same challenge to another client who purposefully claims a different challenge response. We would now have to issue a 3rd challenge to another client and hopefully get a 2:1 vote. But wait - what if this 3rd client also was a malicious verifier? See above collusive clients. This way, they could keep "unwanted competition" from the pool. They could provide specific challenge responses, so when asked for a verification, they would know this is from "one of theirs" and ack it.
Performance Impact: If you knew how the client and the generator worked, you would not speak of "lower the speed a little bit". At this moment, the final address generation and checking pipeline is on GPU. Even if I discard the performance loss and the code complexity of computing that "xor": Moving data not only back from GPU, but also across the network - n-redundantly - even if it worked conceptually, would not be a "little bit" impact.
Executive summary:
SopaXT - you have still lots of things to learn. If you want to make yourself useful and learn new skills beyond TI-82 BASIC programming in a project that actually could provide you an excellent ground for this, you probably should not start by insulting and pissing off the project leader. Then, your knee-jerk-level R&D suggestions would probably be met with more benevolence - maybe even indulgence. Unfortunately you closed that door for yourself a week ago.
In order to spare myself lengthy explanations in future about why the project is doing this or that and why this or that has been decided as it has been decided, this text shall serve as a reference I may (and probably will) point to, when the state "end of discussion" is reached.
This project started - and still is - a spare time project. It's main purpose is to have fun, to learn something and to have distraction from the other ... usual ... daily ... duties.
It's not for profit, it's not for any shady operation, it's for fun. This is 100% true for myself. Everybody is welcome to join under the same ideals. If you have other ideals: FUCK OFF
I want people who participate in the project to have fun also, but if you having fun would mean me having less fun: FUCK OFF
I will not let anybody take that fun away.
You may have heard from various developers (like M. Hearn and others), who plunked their efforts because they were pissed off by their environment.
Well - a week ago, I had a similar moment, but then I thought it should not be me who gets pissed off. When it comes to my leisure time projects, it's actually everybody else who disagrees with the course of action who may piss off. I can be a benevolent dictator in this project (like L. Torvalds is in Linux), but when I choose so I am Pinochet or Mugabe in this project. If anybody has a problem with this mode of operation: FUCK OFF
Now that this is - I hope unambiguously - out of the way, a clear example of such a personal incompatibility is needed:
The Anatomy of a Shitstorm: Genesis
A little over a week ago, 2017-04-16, I have been contacted by a boy named "Mark Boldyrev". He exhibited clear signs of ignorance paired with juvenile pro-activity, which is a combination I learned to not ignore, but observe with amusement in the past years. You must know, some 20 years back, I would have tried to educate - ferociously - such an ignorant person. But with the years I learned to ration my energy in these matters. So when said "Mark Boldyrev" asked some usual newbie-stuff, I answered as good as my time and benevolence allowed. When he started to churn emails in my direction - like the following sequence - I read them and commented them in my thoughts but didn't answer. In the hope the boy may learn during his course of action:
--------
On 2017-04-16 09:36, Mark Boldyrev wrote:
Could you publish all the keys found on the website for the curious?
rico> The 1st 24: https://rya.nc/forensic-bitcoin-cracking.html
rico> some more: https://bitcointalksearch.org/topic/bitcoin-puzzle-transaction-32-btc-prize-to-who-solves-it-1306983
rico> and #38 and beyond (up to #51 now): https://lbc.cryptoguru.org/trophies
--------
On 2017-04-16 10:39, Mark Boldyrev wrote:
Thanks. Could you format them as a comma-separated string, please?
That'd make importing them into my program easier.
rico> A guy named Jude Austin (https://bitcointalksearch.org/user/jude-austin-105076)
rico> has done that and has a spreadsheet with some statistical analysis. Ask him.
--------
As you can see, here I still answered as good as I could - although I did already have a picture of a little ignorant spoiled brat in my head who is used that everybody immediately starts wiping his ass as soon as he whistles. Naturally - as is the usual case with these time vampires - next day he continued and from that moment on I chose to observe and let him fry in his own sauce for a while:
On 2017-04-17 11:17, Mark Boldyrev wrote:
Oh, also, I tried to join LBC, installed the client, but it dies with and error:
Will use 2 CPUs. [~10 sec delay]
Ask for work... Server doesn't like us. Answer: wrong secret.
What should I do? How do I start it (it did the above without any arguments)?
"Yeah, well boy, how about reading a little bit the docs?", I thought
On 2017-04-17 11:33, Mark Boldyrev wrote:
I tried to modify the LBC file and now the server is returning random errors. WTF does that even mean?!
"Whoa there - so you modified the source. You didn't read the manual and you ran into my random error jokery. I love it!", I thought
On 2017-04-17 11:36, Mark Boldyrev wrote:
... did you plant a backdoor in my system? why is the LBC file so volatile? does it check its checksum and report that to server or something? I am really worried about that one...
"3 minutes? The heat is on. Poor bastard.", I thought
On 2017-04-17 15:05, Mark Boldyrev wrote:
Hey!
You didn't respond to my emails, so I posted the warning on Reddit.
And there we go, a backdoor!
You can't deny that, but you still can fix it if you want to regain trust.
This message is not meant to threaten nor harass you.
It is necessary to point out that this was Easter Monday, where a usual family man has, well, family things to attend to, whereas adolescent boys can use this time to verbally masturbate on Reddit.
On 2017-04-17 15:06, Mark Boldyrev wrote:
PS. https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/
Yeah - and from then on it's history.
Now I do believe this boy named "Mark Boldyrev" is "SopaXT". If I am wrong about this, I'm really sorry - but the overall picture is consistent when one looks at the SopaXT PMs:
The problem is that your client is vulnerable by design, with you being the major flaw.
Even if oyu are transparent about the self-removal capability, you still have the ability to run arbitrary code.
Today you delete the clients of users who tampered with them, tomorrow you steal somebody's wallet.
It's already a malicious program that lets you do virtually anything with any computer the program is running on.
It's not yet used for evil, but when it will be, no-one would notice.
You are not competent. Your software has horrible loopholes and it's running on over 200 computers. These loopholes are exploitable by you and there's no reason to trust you. Your pool doesn't have a proper security model and instead relies on the fact that it's supposed to be hard to tamper with the client. I am willing to retract my accusations if you prove that you have removed the backdoor.
etc. etc. yadda yadda
I will bore you no further. I just wanted to show you a premier example of a 100% incompatible person with me, thus with the project. So far. I urged "SopaXT" to keep the mails, print them out and laminate them to look at them in 20 years from now. At a time, when he hopefully has gained more experience, more wisdom and has better control of his testosterone. (I didn't say that - but it goes without saying)
So when all of this is out of the way and my opinion on this is "SopaXT - why are you still here? Just delete the software, or fuck off, or go for heaven's sake on a crusade and recommend everyone to not use the software (you have my blessings)." I actually will answer his Idea of client validation (exceptionally full quote):
Here's an idea for a proof of work that would lower the speed a little bit, but can be checked without executing arbitrary code on the user's machine.
For every n-th private key in the search space, calculate its public key (which is already done in the search process), and XOR a variable with that. => the variable is a xor sum of every n-th public key.
When submitting the work finished message, include the calculated value, too.
To actually prove the work, another trusted client is issued the same task. If the values match, the client is trusted for an interval of time and allowed to submit work.
The next challenge will be randomly issued to the client, and should the client fail it, all the previous work submitted without the challenge shall be recalculated by the pool.
I woke up recently, so my mind is not in its best state. Please point out any silly mistakes I've made, thanks.
For every n-th private key in the search space, calculate its public key (which is already done in the search process), and XOR a variable with that. => the variable is a xor sum of every n-th public key.
When submitting the work finished message, include the calculated value, too.
To actually prove the work, another trusted client is issued the same task. If the values match, the client is trusted for an interval of time and allowed to submit work.
The next challenge will be randomly issued to the client, and should the client fail it, all the previous work submitted without the challenge shall be recalculated by the pool.
I woke up recently, so my mind is not in its best state. Please point out any silly mistakes I've made, thanks.
There are so many things wrong with this, one does not even know where to start. Let's start on the conceptual level:
"another trusted client" is the key phrase here. There is no such thing as no client can be trusted. This alone lets your suggestion fold like a house of cards. But let's for a moment assume, we could somehow get to that "trusted client".
Collusive Clients Attack: Let's say, we would perform these challenges n-redundantly on a group of clients and all of these would agree and confirm each other for the challenge sent. Would that mean we could trust them? Of course not. A clique of collusive clients could do exactly that and as long, as the server couldn't be 100% certain that at least ONE of these clients is valid (which it wouldn't because there would be no higher order validation in this concept), it couldn't be sure about ANY of them. Yeah - sure, the probability would be less and maybe this concept could work in a sufficiently large and distributed clients base. In case you haven't realized: In a situation, where we can have 90% of the pool capacity provided by one man, this is no viable way.
Malicious Verifier Attack: Let's say we issued a challenge to a client and he answered (and correctly so, but we don't know that), so we issue the same challenge to another client who purposefully claims a different challenge response. We would now have to issue a 3rd challenge to another client and hopefully get a 2:1 vote. But wait - what if this 3rd client also was a malicious verifier? See above collusive clients. This way, they could keep "unwanted competition" from the pool. They could provide specific challenge responses, so when asked for a verification, they would know this is from "one of theirs" and ack it.
Performance Impact: If you knew how the client and the generator worked, you would not speak of "lower the speed a little bit". At this moment, the final address generation and checking pipeline is on GPU. Even if I discard the performance loss and the code complexity of computing that "xor": Moving data not only back from GPU, but also across the network - n-redundantly - even if it worked conceptually, would not be a "little bit" impact.
Executive summary:
SopaXT - you have still lots of things to learn. If you want to make yourself useful and learn new skills beyond TI-82 BASIC programming in a project that actually could provide you an excellent ground for this, you probably should not start by insulting and pissing off the project leader. Then, your knee-jerk-level R&D suggestions would probably be met with more benevolence - maybe even indulgence. Unfortunately you closed that door for yourself a week ago.
Jump to: