No non-original firmware is trusted.
None of them prove that their firmware finds blocks before people use it.
Most of them have hacks in them to take hashes.
Almost all of them violate the cgminer license so cannot be trusted.
...
I can't speak to other folk's work, but mine doesn't have "hacks in them" to take hashes; the functionality is documented and I provide the user with 3 different methods of using the firmware, all with full functionality. Paid license, sponsor paid license (i.e., use it on specific pool(s), it acts as a paid license with full funcionality), and a dev-fee supported mode (which, I guess could be 'taking hashes'), depending on your perspective... each of these modes exist at the request of portions of the user base.
Mine also does not violate the GPL for a variety of reasons, the simplest of which is that I do not modify cgminer on-disk and follow the proper linking _recommendations_ in the GPL FAQ in terms of how my additive functionality is implemented.
...
You CAN NOT add or modify #xnsub in a firmware without modifying the cgminer code.
Also, all bitmain miners are built off the cgminer code.
Your Z9_2.3.tar.gz uses a version of cgminer in it - 4.9.0 - I've downloaded it and checked.
You've stated
Change log for version 2.2:
Adds Support for Nicehash (yay!)
Adds proper #xnsub support
Where is the source code to your miner running in your firmware?
That is mandatory if I request it, since I downloaded your binary.
Hopefully frodocooper didn't merit someone for breaking the cgminer license ... ... ...
https://bitcointalk.org/index.php?topic=5151878.msg51403073#msg51403073I hope he didn't merit someone for breaking a license either. I also hope he didn't merit someone for not understanding more advanced things...
I'll give you an example of how you are wrong in your statement of "... cannot add [change/functionally modify/blahblah] without blah blah code..":
https://www.microsoft.com/en-us/research/project/detours/... and here is an example of that type of capability in use in other works:
https://docs.microsoft.com/en-us/windows/msix/psf/package-support-frameworkA significantly simpler way to look at what is going on here is that my work is effectively a custom debugger.
cgminer in Z9_2.3.tar.gz is exactly what bitmain ships, bit for bit and in the example of Z9_2.3.tar.gz, is built on
Antminer-Z11-fixed-718M-201904231321-sig.tar.gz downloaded from bitmain. So, If you want the source to the cgminer in Z9_2.3.tar.gz, then I suggest you do the same thing I've done, and request it from Bitmain.... they've ignored my request, maybe they will not ignore yours.
After that, you can go dig into the GPL faq at #MereAggregation, #GPLCompatInstaller, #DRMProhibited, #GiveUpKeys, and #GPLPlugins, among others for the relevant portions of how the portions which are "my" firmware (which is not anything bitmain ships, that is on them, legally and ethically) are not applicable. Other portions which are, you already have the source code to by proxy of downloading the bundle itself (javascript/html in /www/pages/*).
Two short examples are that my work does not "make function calls to each other" or "share data structures", and by proxy of #GPLPlugins, are not in fact covered by "form a single combined program". Further, ".. communications between them is limited to invoiking the main function of the plug-in with some options and waiting for it to return, that is a borderline case".
Further, if my loader (read: installer) and associated work (read: drm, giveupkeys, etc.) only use the publicly documented APIs (which it does), then it is not a GPL derived work (also, GPL FAQ, but I haven't had my coffee yet this AM and am missing a quick location to the reference).
-j
