Bitcoin Forum
November 05, 2024, 10:37:04 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: On BFGMiner and CGMiner - who ripped who off?  (Read 7369 times)
K1773R (OP)
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
January 31, 2013, 09:20:32 AM
 #21

Continue the banter here, gents.
nice Smiley clean references Tongue ty

[GPG Public Key]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
-ck
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
January 31, 2013, 10:03:21 AM
Last edit: January 31, 2013, 10:17:37 AM by ckolivas
 #22

Forks I don't have a problem with.

I do not for a second deny that the "device API", as luke-jr calls it, was first written by him, as was the first BFL driver for cgminer. However this was all code for cgminer at the time, and the code has been heavily rewritten since then.

Calling cgminer a fork of luke-jr's version has got to be one of the most ridiculous lies I have ever heard regarding code.

Initial revision of cpuminer (Nov 25 2010) https://bitcointalk.org/index.php?topic=1925.0 :
https://github.com/ckolivas/cgminer/commit/9599867d8b9ddd909ea3dc37679b34cab5de5674
Jeff Garzik committed 2 years ago
Version 1.0 of cpuminer: May 09, 2011 Jeff Garzik authored 2 years ago

First commit by me to cpuminer: Jun 08, 2011
https://github.com/ckolivas/cgminer/commit/8a832eeab524bbad160adb7c27acb370d6adedff

First GPU mining code added to cpuminer code by me: June 23, 2011,
https://bitcointalk.org/index.php?topic=1925.msg264355#msg264355

First release by me under cgminer name superceding cpuminer: July 13, 2011
https://bitcointalk.org/index.php?topic=1925.msg357421#msg357421

etc...

First release of bfgminer as fork of cgminer: Apr 26, 2012
https://github.com/luke-jr/bfgminer/commits/bfgminer-2.3.4

Luckily history on the internet is there to make any such claims truly absurd. Simply reading the changelog and timeline of each is enough to show it would be absurd to think that bfgminer somehow predated cgminer when bfgminer didn't even exist for the first 9 months of development that cpuminer became cgminer. Yes, luke-jr contributed code to cgminer... this was when cgminer was the only maintained code around based on Jeff Garzik's original cpuminer.

The "reason" luke-jr created the fork to cgminer was that he contributed code to cgminer that was rejected by me based on evidence provided by Kanoi that it was buggy, but he just wanted the code out despite the issues with the code which I refused to accept as the concerns were valid. Creating a fork because you want to get new code out that introduces many regressions is not an unusual practice on the internet, and is unfortunately only counter productive to the development process, especially when the original code source is still being actively maintained. Once he had forked his version, 99% of the cgminer code continues to go to his fork, and 1% of the cgminer code came from his fork. One unfortunate thing is that the git source control management system tells you who committed code to a source tree (such as bfgminer), but not who actually wrote the code. Follow the parent of the code tree on github on bfgminer and you'll see it was basically mostly code pulled from cgminer that I and kanoi have written. On the other hand, I have gone out of my way to avoid taking almost any code from luke-jr's fork unless it is actually a bugfix or -in the case of the bfl flash code for linux- a feature I will never bother coding myself. That means that since the fork, 99% of the code in cgminer has nothing to do with luke-jr. I even went to the extent of developing my own GBT implementation, which is the communication protocol invented by luke-jr (that I dislike immensely compared to stratum) from scratch rather than use his already existing "reference implementation" because his code was python and it would be more efficient coded by myself in c instead.

It is very easy to side with a camp that you happened to start using first, and even harder to consider you might have sided with the wrong camp if you came on the scene late in the development process. Look at the history of luke-jr throughout bitcoin history and across this forum and you'll find an amazing record of behaviour you wouldn't trust as far as you could throw him. Whenever questioned about something he either simply says "it's not true" or "I don't lie" or doesn't respond, or appeals to a forum moderator to have the post deleted as a troll. He has also never been known to back down on an argument, say he's wrong or accept any form of leadership, constantly trying to take charge - so far as leading to a huge battle between the lead bitcoin maintainer, Gavin Andresen, and himself on one of the BIP issues. Kano is an annoying prick, but he produces evidence to support everything he says on the forum and will graciously say when he's wrong.

I try very hard to keep out of these discussions because I believe code and data speaks louder than words, and am primarily a coder and totally utterly flabbergasted by this whole ridiculous discussion and when one compares the hostile fork to cgminer I can only shake my head. Once upon a time I thought that code speaks louder than words and the truth shows its face over time. However I have come to realise that if you don't go to at least some effort to defend yourself, you get desperately misrepresented.

Reading anything luke-jr has to say just aggravates me because of many of his claims, including things like saying cgminer is "deprecated" while it is clearly still being actively maintained, and writing that it has some kind of substandard FPGA support when he ends up copying code from cgminer's FPGA code implementation. This is why I have luke-jr on ignore. What astounds me more than anything else, in light of this evolution of events, is his persistence in the face of all logic and reason.

That is all.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 4620
Merit: 1851


Linux since 1997 RedHat 4


View Profile
January 31, 2013, 10:05:29 AM
 #23

Firstly, just with regards to the stupid name that the idiot used for the device_api (that he even stated that he copied ideas from ckolivas in his own commits) and also when already months before it there existed the RPC API
I have renamed it to device_drv for 2 specific reasons:
1) searching for API related stuff and device_drv related code is now as simple as searching for those two - now different - terms drv and api
2) The source files are called: driver-bitforce.c driver-icarus.c driver-modminer.c driver-opencl.c driver-ztex.c - so yeah the new name suits well.
https://github.com/kanoi/cgminer/commit/fe508bacf07eec4e8750e5c402a92467f9ea7384

Now as I said above, the idiot even stated in his own commits that he copied ideas into the old device_api
https://github.com/ckolivas/cgminer/commit/a4d1fe1e5d116851d45624496327445db9660ff0

Both ckolivas and myself have added (and replaced) code in the old device_api and that code has been copied to the clone.

A bunch of git proof that he copied stuff and claims it as his own and also has delusions about his grandeur regarding how "It's his":
https://bitcointalk.org/index.php?topic=78192.msg1467026#msg1467026 (followed 2 posts later by a clone release full of new cgminer code)
https://bitcointalk.org/index.php?topic=28402.msg1466079#msg1466079
https://bitcointalk.org/index.php?topic=28402.msg1477922#msg1477922
https://bitcointalk.org/index.php?topic=28402.msg1478484#msg1478484
https://bitcointalk.org/index.php?topic=28402.msg1467323#msg1467323
https://bitcointalk.org/index.php?topic=28402.msg1467532#msg1467532

... and of course the ultimate commit proof by stupid himself:
https://bitcointalk.org/index.php?topic=78192.msg1467026#msg1467026
That he states it's fork, changes the name "cgminer" in most places and also changes the donation address to him

And just to show what a pissy little small minded guy he is, when he added himself to the list of authors, instead of adding himself to the end, he added his name above mine:
https://github.com/kanoi/cgminer/commit/9e40e87a1ed1003734a3aae114f7d1ac0643469d

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
nathanrees19
Full Member
***
Offline Offline

Activity: 196
Merit: 100



View Profile
January 31, 2013, 10:35:40 AM
 #24

i hate ppl who do lie
It's not healthy to hate yourself.

BTW, I don't lie.

To a casual observer, many of your posts appear to be more than a little bit misleading. If your statement is true (considering that, statistically, liars say it more often), then it is so only by technicality.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
January 31, 2013, 01:43:55 PM
 #25

i hate ppl who do lie
It's not healthy to hate yourself.

BTW, I don't lie.

To a casual observer, many of your posts appear to be more than a little bit misleading. If your statement is true (considering that, statistically, liars say it more often), then it is so only by technicality.
Care to elaborate? While I don't hestitate to put mental reservation into use for good reason (such as keeping others' secrets) and sometimes leave out technical details that are irrelevant and I cannot easily explain to the audience, and sometimes I may even be mistaken, nothing I say is known by me to be false at the time.



The "reason" luke-jr created the fork to cgminer was that he contributed code to cgminer that was rejected by me based on evidence provided by Kanoi that it was buggy, but he just wanted the code out despite the issues with the code which I refused to accept as the concerns were valid.
Really? What evidence was that? When did you ever show any interest in FPGAs before you got upset over the ASIC announcement, for that matter?

No, you intentionally-blindly accepted Kano's revert of all the improvements and bugfixes I had made to the Icarus driver on Kano's whim.
Furthermore, the Windows compatibility Kano pointed out was broken, was not ignored, but easily fixed without reverting any of the improvements or bugfixes.
Do you junk your new car just because someone finds one of the fuses is popped, or do you just fix the problem and move forward?

One unfortunate thing is that the git source control management system tells you who committed code to a source tree (such as bfgminer), but not who actually wrote the code. Follow the parent of the code tree on github on bfgminer and you'll see it was basically mostly code pulled from cgminer that I and kanoi have written.
No, git handles attribution just fine - when used correctly. While you and Kano regularly misattribute your commits based on code from others, I make good use of the --author option to give credit to the person who wrote the code.
Considering you've claimed you never look at BFGMiner code, it's ironic you claim it's mostly code pulled from cgminer. I encourage anyone who knows his way around git (even github's web interface isn't too bad) and has any doubts about this, to look at the code themselves and see plainly where BFGMiner code came from or didn't.

I even went to the extent of developing my own GBT implementation, which is the communication protocol invented by luke-jr (that I dislike immensely compared to stratum) from scratch rather than use his already existing "reference implementation" because his code was python and it would be more efficient coded by myself in c instead.
That's called the not-invented-here syndrome. Also, libblkmaker is and always has been standard C.

Whenever questioned about something he either simply says "it's not true" or "I don't lie" or doesn't respond, or appeals to a forum moderator to have the post deleted as a troll.
No, that's how I handle trolls and claims with no basis in the truth (usually repeated from a troll). These are pretty standard recommended ways of dealing with trolls.
That I let any posts like this one of yours trick me into wasting time responding, I guess is my own fault.

He has also never been known to back down on an argument, say he's wrong or accept any form of leadership, constantly trying to take charge - so far as leading to a huge battle between the lead bitcoin maintainer, Gavin Andresen, and himself on one of the BIP issues.
While I don't generally abandon functionality I need (or else I wouldn't have taken the time to write it in the frist place!), I regularly act to make them more compatible with others' objections. It's not unheard of for others to convince me that I'm wrong either, though that takes actual logic, not mere trolling like you and Kano enjoy doing. Even while BIP 16 is the P2SH solution adopted by Bitcoin, it doesn't take a rocket scientist to see that BIP 17 was the superior solution - but that's all ancient history now.

Reading anything luke-jr has to say just aggravates me because of many of his claims, including things like saying cgminer is "deprecated" while it is clearly still being actively maintained, and writing that it has some kind of substandard FPGA support when he ends up copying code from cgminer's FPGA code implementation.
cgminer is pretty much deprecated - as a GPU miner, in a world that has moved on from GPUs. cgminer's FPGA code, which came from and was maintained mostly by myself until you cut it off from its main development branch, is horribly outdated and mostly only grown worse as Kano incompetently tried to "improve" it - so your choice of "substandard" here is pretty accurate!

crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
January 31, 2013, 03:33:54 PM
 #26

Reading anything luke-jr has to say just aggravates me because of many of his claims, including things like saying cgminer is "deprecated" while it is clearly still being actively maintained, and writing that it has some kind of substandard FPGA support when he ends up copying code from cgminer's FPGA code implementation.
cgminer is pretty much deprecated - as a GPU miner, in a world that has moved on from GPUs. cgminer's FPGA code, which came from and was maintained mostly by myself until you cut it off from its main development branch, is horribly outdated and mostly only grown worse as Kano incompetently tried to "improve" it - so your choice of "substandard" here is pretty accurate!
ROFL didn't you just say a few days ago that the GPU code in CGMiner and BFGminer are almost exactly the same? So why are you calling his GPU code "deprecated" and your isn't? And as much as you don't like Kano, or you don't like the changes he's making to FGPA, USB, or ASIC code, you simply just can't call his software "deprecated" if it's still being actively maintained and worked on.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
January 31, 2013, 03:36:30 PM
 #27

Reading anything luke-jr has to say just aggravates me because of many of his claims, including things like saying cgminer is "deprecated" while it is clearly still being actively maintained, and writing that it has some kind of substandard FPGA support when he ends up copying code from cgminer's FPGA code implementation.
cgminer is pretty much deprecated - as a GPU miner, in a world that has moved on from GPUs. cgminer's FPGA code, which came from and was maintained mostly by myself until you cut it off from its main development branch, is horribly outdated and mostly only grown worse as Kano incompetently tried to "improve" it - so your choice of "substandard" here is pretty accurate!
ROFL didn't you just say a few days ago that the GPU code in CGMiner and BFGminer are almost exactly the same? So why are you calling his GPU code "deprecated" and your isn't? And as much as you don't like Kano, or you don't like the changes he's making to FGPA, USB, or ASIC code, you simply just can't call his software "deprecated" if it's still being actively maintained and worked on.
I'm calling GPU mining in general deprecated. BFGMiner had FPGAs as the focus from the start; OpenCL support is there mainly because it doesn't hurt anything. BFGMiner also supports CPU mining. Both CPU and GPU mining are deprecated.

crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
January 31, 2013, 03:45:00 PM
 #28

I've read enough of these Kano/LukeJR debates. Here's how it usually goes:

LJR: Everybody stop using CGMiner! BFGminer is better in every aspect!
Kano: Troll, you just copied CGMiner.
LJR: No, you copied BFGminer and my code.
Kano: Here's the git to prove my claims. Where's your proof?
LJR: You're a liar.
Everyone else: Why doesn't LJR offer proof to defend himself?

In most cases, Kano offers substantical proof, either from Git or Irc. Luke just complains that he's being oppressed and trolled.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
January 31, 2013, 03:47:52 PM
 #29

Reading anything luke-jr has to say just aggravates me because of many of his claims, including things like saying cgminer is "deprecated" while it is clearly still being actively maintained, and writing that it has some kind of substandard FPGA support when he ends up copying code from cgminer's FPGA code implementation.
cgminer is pretty much deprecated - as a GPU miner, in a world that has moved on from GPUs. cgminer's FPGA code, which came from and was maintained mostly by myself until you cut it off from its main development branch, is horribly outdated and mostly only grown worse as Kano incompetently tried to "improve" it - so your choice of "substandard" here is pretty accurate!
ROFL didn't you just say a few days ago that the GPU code in CGMiner and BFGminer are almost exactly the same? So why are you calling his GPU code "deprecated" and your isn't? And as much as you don't like Kano, or you don't like the changes he's making to FGPA, USB, or ASIC code, you simply just can't call his software "deprecated" if it's still being actively maintained and worked on.
I'm calling GPU mining in general deprecated. BFGMiner had FPGAs as the focus from the start; OpenCL support is there mainly because it doesn't hurt anything. BFGMiner also supports CPU mining. Both CPU and GPU mining are deprecated.
So if Miner A and Miner B both support CPU and GPU mining, and you think said features are deprecated, why is Miner A deprecated, but Miner B isn't, when they're both still being actively maintained and developed?

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
kano
Legendary
*
Offline Offline

Activity: 4620
Merit: 1851


Linux since 1997 RedHat 4


View Profile
January 31, 2013, 10:44:11 PM
 #30

i hate ppl who do lie
It's not healthy to hate yourself.

BTW, I don't lie.

To a casual observer, many of your posts appear to be more than a little bit misleading. If your statement is true (considering that, statistically, liars say it more often), then it is so only by technicality.
Care to elaborate? While I don't hestitate to put mental reservation into use for good reason (such as keeping others' secrets) and sometimes leave out technical details that are irrelevant and I cannot easily explain to the audience, and sometimes I may even be mistaken, nothing I say is known by me to be false at the time.



The "reason" luke-jr created the fork to cgminer was that he contributed code to cgminer that was rejected by me based on evidence provided by Kanoi that it was buggy, but he just wanted the code out despite the issues with the code which I refused to accept as the concerns were valid.
Really? What evidence was that? When did you ever show any interest in FPGAs before you got upset over the ASIC announcement, for that matter?

No, you intentionally-blindly accepted Kano's revert of all the improvements and bugfixes I had made to the Icarus driver on Kano's whim.
Furthermore, the Windows compatibility Kano pointed out was broken, was not ignored, but easily fixed without reverting any of the improvements or bugfixes.
Do you junk your new car just because someone finds one of the fuses is popped, or do you just fix the problem and move forward?

One unfortunate thing is that the git source control management system tells you who committed code to a source tree (such as bfgminer), but not who actually wrote the code. Follow the parent of the code tree on github on bfgminer and you'll see it was basically mostly code pulled from cgminer that I and kanoi have written.
No, git handles attribution just fine - when used correctly. While you and Kano regularly misattribute your commits based on code from others, I make good use of the --author option to give credit to the person who wrote the code.
Considering you've claimed you never look at BFGMiner code, it's ironic you claim it's mostly code pulled from cgminer. I encourage anyone who knows his way around git (even github's web interface isn't too bad) and has any doubts about this, to look at the code themselves and see plainly where BFGMiner code came from or didn't.

I even went to the extent of developing my own GBT implementation, which is the communication protocol invented by luke-jr (that I dislike immensely compared to stratum) from scratch rather than use his already existing "reference implementation" because his code was python and it would be more efficient coded by myself in c instead.
That's called the not-invented-here syndrome. Also, libblkmaker is and always has been standard C.

Whenever questioned about something he either simply says "it's not true" or "I don't lie" or doesn't respond, or appeals to a forum moderator to have the post deleted as a troll.
No, that's how I handle trolls and claims with no basis in the truth (usually repeated from a troll). These are pretty standard recommended ways of dealing with trolls.
That I let any posts like this one of yours trick me into wasting time responding, I guess is my own fault.

He has also never been known to back down on an argument, say he's wrong or accept any form of leadership, constantly trying to take charge - so far as leading to a huge battle between the lead bitcoin maintainer, Gavin Andresen, and himself on one of the BIP issues.
While I don't generally abandon functionality I need (or else I wouldn't have taken the time to write it in the frist place!), I regularly act to make them more compatible with others' objections. It's not unheard of for others to convince me that I'm wrong either, though that takes actual logic, not mere trolling like you and Kano enjoy doing. Even while BIP 16 is the P2SH solution adopted by Bitcoin, it doesn't take a rocket scientist to see that BIP 17 was the superior solution - but that's all ancient history now.

Reading anything luke-jr has to say just aggravates me because of many of his claims, including things like saying cgminer is "deprecated" while it is clearly still being actively maintained, and writing that it has some kind of substandard FPGA support when he ends up copying code from cgminer's FPGA code implementation.
cgminer is pretty much deprecated - as a GPU miner, in a world that has moved on from GPUs. cgminer's FPGA code, which came from and was maintained mostly by myself until you cut it off from its main development branch, is horribly outdated and mostly only grown worse as Kano incompetently tried to "improve" it - so your choice of "substandard" here is pretty accurate!
Interesting that nothing here you have stated actually includes any git proof - you have methods in git to prove it but since there is no proof in those methods (i.e. what you have said is a lie) you simply resort to "Luke-Jr is God and what he says is true - no proof required" and everyone else is a troll.

As for my so called "incompetence" using a single direct libusb rather that a collection of different serial libraries that have problems interacting with each other - well we'll see wont we Cheesy
(and of interest ... the Avalon 'queue' isn't really a 'queue' it's simply sending a list of work items all at the same time when new work is required - so that should be a simple performance gain moving it to USB ... if the code is ever released Tongue)

The issue about who first wrote the Icarus LP code is here ... and of course the discussion about the original Icarus code:
(this is basically the main issue that keeps being brought up regarding why the fork even exists)
https://bitcointalk.org/index.php?topic=90656.msg1003391#msg1003391
https://bitcointalk.org/index.php?topic=28402.msg1000946#msg1000946
https://bitcointalk.org/index.php?topic=28402.msg997424#msg997424
https://bitcointalk.org/index.php?topic=28402.msg834153#msg834153
https://bitcointalk.org/index.php?topic=28402.msg782479#msg782479

The original LP problem, as you know, with the Icarus windows code, was:
I had written my changes before you and discussed them in IRC and tested them on linux for weeks and had stated I hadn't sent the pull request BECAUSE I had not tested it on windows yet (my windows VM had screwed up and I hadn't got around to rebuilding it)
You followed up by sending a pull request of code you HAD NOT TESTED on windows.
It DIDN'T WORK on windows.
I used sharky112065's new windows setup script to create a new windows VM and testing both your and my code on windows.
Both your and my code had windows problems.
My fix didn't fix yours - I tried and tested that and stated that.
So my code (which now did work) replaced your code in cgminer ... which again ... mine had been written first and tested on linux first by Xiangfu with a farm of Icarus devices for weeks.

Of course Luke-Jr has tried to prove another of his lies in the not too distant past that lead to this:
https://bitcointalk.org/index.php?topic=28402.msg1090242#msg1090242
Which he then followed up to me: "Would you prefer I shut up or apologize publicly?"
Maybe that's why he doesn't try to prove his lies? He knows I will specifically disprove the lies he makes to defend himself if it annoys me enough.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
-ck
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
January 31, 2013, 11:17:20 PM
 #31

Unfortunately the forum does not block what luke-jr writes when someone quotes him even if I do have him on ignore Angry.

How I feel about FPGAs and ASICs has nothing to do with your claims. If I were to call it, I'd say you were upset because I was planning to exit the scene with FPGAs but ASICs changed the scene and I indeed changed my mind so you didn't get to take over.

The internet now has a vast history of the events yet you continue to dispute it as though you actually believe it. I used to joke about it, but I'm really becoming convinced you have a personality disorder now. As a doctor, I do diagnose these conditions in the real world. If over time you end up having a problem with the rest of the world, perhaps it's not the rest of the world at fault.

Show something about the code.
Prove something useful.
Respond about objective things.
Show some humility.

Look at what he wrote in response and see for yourselves how much it precisely matches the pattern I, and many others, described, and try and find the evidence in his response to support his outlandish claims that aren't just baseless attacks.

This is precisely why I avoid these discussions in the first place and ignore his posts. Responding is just troll feed. I shall stop monitoring this thread.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!