Re: PhoenixMiner 2.6: fastest Ethereum/Ethash miner with lowest devfee (Windows)
@PhoenixMiner:
you use my GPU kernels in your "fastest" miner, 100% match of binaries. I can prove it if you are not going to confirm it.
So do you confirm it?
No, we certainly DO NOT confirm it. We believe that you've tried (and apparently you think you succeeded) in extracting our kernels using reverse engineering techniques. That wasn't very nice of you to say the least but we have expected something like this, just not that fast. In some sense it is flattering but also a little annoying.you use my GPU kernels in your "fastest" miner, 100% match of binaries. I can prove it if you are not going to confirm it.
So do you confirm it?
The first version of our kernels was obtained from someone on this very forum for quite a bit of coins. They were a little bit slower than the best miner on the market at this time - yours - but we decided to use them to jump start our project anyway. After a lot of tinkering with Polaris GPUs we found out how to increase the speed a bit and improved the kernels a lot, achieving higher speed and/or lower consumption than your miner (in most cases). The original versions were left as a honeypot for particularly persistent reverses which apparently did its job quite well
Now, are these old kernels the same as old versions of yours? We don't know for sure but we doubt it, and we can't just take your word for it (especially after throwing accusations like this after basically admitting that YOU are trying to reverse OUR miner), and because they were slower than your miner, and they do not support dual mining at all (and dual mining is still the killer feature). But even if they were, frankly this isn't our problem - we've paid handsomly for them, and we haven't used them in any of the publicly released versions, so we won't lose any sleep over this. If you beleive so, search for a digruntlet employee, or perhaps your unnamed source(s) at AMD?
I decided to check your miner as soon as I noticed that you have same tuning option ("+" and "-" keys in runtime) that works exactly as my -dcri option, also your miner has no "optimized" kernels for same set of chips as my miner. After checking I found 100% match in GPU kernel on GPU.
Now you are talking about some "old unknown" kernels and you don't use them anymore and have super-protection that can fool me and so on... okay.
I will create step-by-step guide how to confirm that you send my kernels to GPU and you will say that your miner uses "old unknown" kernels because it detects dumping but still mines at the same speed. That's funny answer, but you don't have better one, I understand.
So my word against yours. The result is obvious for me, however, since I call you a liar, anyone who wants to confirm by yourself that this miner uses my kernels can PM me and I will send step-by-step guide how to do it, then you can say the results; no newbies please, be at least sr.member on this forum, just to be sure that you don't want to become another "phoenixminer" and spend my time again...
Do what you've got to do of course - obviously you feel strongly about this and believe that this is well worth your time
It's just not exactly clear what you are trying to prove though - we already conceded that our old/honeypot kernels might be the same as your old kernels but this is not very likely. But since you are willing to provide the blobs of your kernels in these PM sessions, our kernel guy would certainly like to take a look, so thank you.Frankly we've got a lot of respect for you, and if you have chosen to contact us via PM with your concerns, we would have respected that and checked if there is any merit in your claims but you've come swinging and accusing us in our thread and if you expect us to just sit there and take it, you are quite wrong.
It is also quite wrong of you to assume these things:
- That you can't be fooled by our anti-reversing measures (really do you think that we can't detect dll-injection attacks?).
- And that, if you do succeed in extracting our real/current kernels and leak them in the open, we can't do the same with yours. "We know" a guy that was part of the driver development team of AMD and he is itching to test its kernel-level emulator by trying to extract your current kernels. Heck, if he's successful, we can even put your kernels in our miner and let the users select them explicitly and see for themselves how they compare with ours.
Anyway, we prefer to concentrate our efforts on improving our miner bit by bit (we are still lacking in many areas) but if you want to play this game, we can play it too. Just keep in mind that we were nobody in comparison with you just a few weeks ago, and you seem resolute to put us on the map so to speak, for which we thank you - it well known that controversial or bad publicity is always better than no publicity at all.