Quite a number of people have suggested to me adding a donation option to cgminer as an opt-out feature. This would redirect a nominal amount of shares, say 0.5% to myself, which could be disabled on the command line. I've been resisting taking such an approach, but how do other people feel about that? It would certainly make me happier to keep supporting this project.
I think this is a great idea.
|
|
|
Added a simple ebuild for dev-util/amd-adl-sdk to the bitcoin overlay. Please test. (no manual downloading required)
|
|
|
No one can provide the ADL support except ATI/AMD. (and I'm certain they won't have what you are looking for - only the download SDKs) Any source build linux thus cannot provide the whole of cgminer. You must (by the terms of their license) get the ADL/SDK code from them and manually install it. More cluelessness from kano. Learn to research before commenting, please. Ever heard of the term foot-in-mouth? AMD-APP-SDK-v2.4-lnx64/docs/opencl/LICENSES Thankfully, I don't need a license to write an ebuild.
|
|
|
No one can provide the ADL support except ATI/AMD. (and I'm certain they won't have what you are looking for - only the download SDKs) Any source build linux thus cannot provide the whole of cgminer. You must (by the terms of their license) get the ADL/SDK code from them and manually install it. More cluelessness from kano. Learn to research before commenting, please.
|
|
|
So I tested and reported My report seemed clear : Portage mentioned an unsatisfied dependency. As your post simply mentioned the bitcoin overlay, it seems the dependency is wrong, can't be fullfilled or the ebuild it depends on is in another overlay (should I really explain this to someone writing an ebuild ?). Would you be kind enough to choose one of these 3 possible reasons (or whatever 4th you may find more suitable) and help from here (is it my task to write the missing ebuild, is there another overlay you forgot to mention, ...). If you need ADL support, you'll probably have to write the missing ebuild-- I don't know of any yet. ADL support is controlled by the 'adl' USE flag and should be disabled by default-- ie, you shouldn't be getting this error with a simple 'emerge cgminer'
|
|
|
That was part of the complaint about what he was doing. There was no legitimate complaints, only trolls.
|
|
|
Cgminers binaries compiled for Ubuntu 64 bit with adl work (temp/fan/freq monitoring/setting works). Your ebuild depends on another that isn't provided in the bitcoin overlay nor the Portage tree. That's an effect of using a from-source distro: you need build dependencies.
|
|
|
More important than any of that is DOCUMENTATION. On the protocol, not the patches assuming I want to risk the main pool operation.
|
|
|
NEW VERSION: 2.0.4 Now available for Gentoo through Portage (or any other ebuild package manager): layman -a bitcoin && emerge cgminer Please test and report results! emerge: there are no ebuilds to satisfy "dev-util/amd-adl-sdk" I have dev-util/amd-app-sdk-bin though. APP SDK isn't enough for the ADL features. You should be able to build with USE=-adl
|
|
|
Hi I run a pool that takes a different approach to pool servers. I use many servers and not just one and round robin them on one domain. CGIMine is the only miner I know of that does not stick to the one ip when it makes get work requests and submitting its work thus it would get work from one server on the round robin and submit it to another that rejects it. This is a bug on your end. The solution is to get your pool servers to share their work log.
|
|
|
I'm happy to see you here Luke! did you test cgminer against eligius? In earlier versions cgminer reported a lot of rejections with your pool. Pretty sure all those bugs were fixed with 2.0.0.
|
|
|
NEW VERSION: 2.0.4 Now available for Gentoo through Portage (or any other ebuild package manager): layman -a bitcoin && emerge cgminer Please test and report results!
|
|
|
This would fork the blockchain. More useful changes have been kept-out-until-later for that reason.
|
|
|
For the love of separation of concerns and other sound software engineering principles I'm against combining a command line RPC client and a GUI server/native client in one executable. Speaking as a non-developer user I would love to see a complete separation between the two. You can already run bitcoind+Spesmilo
|
|
|
I don't know if it's been fixed since I noticed it, but at least some version of it is lacking the ability to enable/disable UPnP support at compile-time. It also adds an implementation of bitcoin: URIs that is not compatible with the existing established/in-use standard. BTW, I don't like QT... It is a ugly toolkit... GTK3 is much nicer... But, I appreciate the effort!! Qt supports GTK2 right now, at least. I expect it will support GTK3 soon.
|
|
|
It's probably worth changing DecodeBase64 to throw a "malformed base-64 encoding" exception if "left" is not zero when exiting the while(1) loop. If this "strict format check" is adopted then one should also check that an "=" character caused the loop termination. Considering that there is no one Base64 standard and the fact that signing is not a 1:1 input:signature mapping in any case, it's probably sensible to tolerate variation as much as possible.
|
|
|
This (or any redirection of "stolen" funds) is legally questionable. But keeping it, or redirecting it back to the thief is ok? I'm not redirecting it to myself, no. A pool can make its own rules, no contract is signed between the pool and the miners (or bot net), I dont see the problem. A pool could donate my share to a charity, if I dont like that, I can only switch pools. ... or if you have a botnet, you can DDoS the pool for making rules you don't like, which we already have enough of without asking for more.
|
|
|
Im curious what you are doing about the botnet? Nothing I can do. Anyone think it would be a good idea to keep it mining, but send the payouts to some charity? This (or any redirection of "stolen" funds) is legally questionable.
|
|
|
More DDoS havoc this morning. For future incident reports, please check our forum.
|
|
|
|