Topic: New .Net Miner (now with GPU and long poll!) - page 3. (Read 8487 times)
Ok, gonna download VS10 and check how it works
No. It uses Linq in a few places. 4.0 only.
Will it work with NET 2.0 libraries?
1. package this in sccm or $package_management_tool and deploy across a bank or other FI.
2. have the bank's computers mining bitcoins.
3.
4. Profit!
5. Go to jail.
Hahaha, this.2. have the bank's computers mining bitcoins.
3.
4. Profit!
5. Go to jail.
Reminds me of the ABC guy who added the miner to their website.
GPU support added.
this proejct definitely shows some great potential, and i'll gladly beta test it as soon as the GPU bit is working
Anyways, the point for me is to deploy it across a heterogeneous range of desktops and servers, none of which I have the time or ability to make sure are all running the same GPUs, or same drivers. So the point of this project is to make sure one miner can figure out the best way to run on the box it lands on.
Sounds perfect for a botnet owner!
But seriously, awesome work, sounds like it could be useful to people who own large corporations and want to deploy it to all their employees computers, but not interrupt their work
1. package this in sccm or $package_management_tool and deploy across a bank or other FI.
2. have the bank's computers mining bitcoins.
3.
4. Profit!
5. Go to jail.
2. have the bank's computers mining bitcoins.
3.
4. Profit!
5. Go to jail.
Great work. Been waiting for something like this.
New Bitcoin miner available.
http://github.com/wasabii/BitMaker
It's GPLv3, for now, until I come up with reasons to make it less restricted.
The majority of it is written in C#, including a purely managed miner component. There is an SSE miner component that is written in C++/CLI. This component won't run on Mono. The rest does. I'd like to fix that by using some P/Invoke instead of C++/CLI, but that's outside of the scope of my current interests.
I will be working on GPU support using Cloo, shortly. My goal with writing this was to have a flexible code base that I could use to deploy miners across my company's desktop, and maintain enough control over it to ensure that it doesn't disturb normal operations. Also: lulz.
One of the primary motivations with the GPU support will be it running as a Windows service, not on the user's desktop, so as not to interfere with the user's session. This will be interesting to do while still ensuring access to the GPU.
The architecture uses MEF to dynamically load miner plugins. Miner plugins advertise themselves as supporting certain resources (such as an instance of CpuResource). If two plugins can work with the same resource, the host tests both of them and chooses the one with the best hash rate. This is kind of silly right now with only a ManagedMiner and a SseMiner, which of course both use a CPU, and one being a clear winner. It might make more sense as I start filling in GPU support, and building different kernels for different brands and models of GPUs. Or maybe it's overkill. Either way: lulz.
No long pull support yet. That should be simple to add, and I'll be on it shortly. I've been testing against Slush's pool, so it hasn't really been something that I've bothered to do.
Anyways, the point for me is to deploy it across a heterogeneous range of desktops and servers, none of which I have the time or ability to make sure are all running the same GPUs, or same drivers. So the point of this project is to make sure one miner can figure out the best way to run on the box it lands on.
Anyways, enjoy. If there are any .Net developers out there that have been looking for a miner to fart with, this might be it.
UPDATE
GPU support added. Basically using Diablo's kernel for now. Not a whole lot is configurable, and I'm thinking of keeping it that way. I already have a framework in place to auto select the best miner for a particular piece of hardware, so I'd like to extend that to automatically try various work size, vector, etc, settings, and pick the option that results in the best performance.
Now that that works, I'm going to start working on splitting the GPU stuff off into a separate process, and communicating with it using IPC. I have code that will let me, from a service running in Session 0, spawn processes in other sessions, such as on the logon screen, or the logged in user's session. This will allow me to access the GPU from a service.
Long Poll support added.
Now supports failover pools.
RELASE
https://github.com/wasabii/BitMaker/downloads
Edit BitMaker.Console.exe.config to set your pool url, for now.
http://github.com/wasabii/BitMaker
It's GPLv3, for now, until I come up with reasons to make it less restricted.
The majority of it is written in C#, including a purely managed miner component. There is an SSE miner component that is written in C++/CLI. This component won't run on Mono. The rest does. I'd like to fix that by using some P/Invoke instead of C++/CLI, but that's outside of the scope of my current interests.
I will be working on GPU support using Cloo, shortly. My goal with writing this was to have a flexible code base that I could use to deploy miners across my company's desktop, and maintain enough control over it to ensure that it doesn't disturb normal operations. Also: lulz.
One of the primary motivations with the GPU support will be it running as a Windows service, not on the user's desktop, so as not to interfere with the user's session. This will be interesting to do while still ensuring access to the GPU.
The architecture uses MEF to dynamically load miner plugins. Miner plugins advertise themselves as supporting certain resources (such as an instance of CpuResource). If two plugins can work with the same resource, the host tests both of them and chooses the one with the best hash rate. This is kind of silly right now with only a ManagedMiner and a SseMiner, which of course both use a CPU, and one being a clear winner. It might make more sense as I start filling in GPU support, and building different kernels for different brands and models of GPUs. Or maybe it's overkill. Either way: lulz.
No long pull support yet. That should be simple to add, and I'll be on it shortly. I've been testing against Slush's pool, so it hasn't really been something that I've bothered to do.
Anyways, the point for me is to deploy it across a heterogeneous range of desktops and servers, none of which I have the time or ability to make sure are all running the same GPUs, or same drivers. So the point of this project is to make sure one miner can figure out the best way to run on the box it lands on.
Anyways, enjoy. If there are any .Net developers out there that have been looking for a miner to fart with, this might be it.
UPDATE
GPU support added. Basically using Diablo's kernel for now. Not a whole lot is configurable, and I'm thinking of keeping it that way. I already have a framework in place to auto select the best miner for a particular piece of hardware, so I'd like to extend that to automatically try various work size, vector, etc, settings, and pick the option that results in the best performance.
Now that that works, I'm going to start working on splitting the GPU stuff off into a separate process, and communicating with it using IPC. I have code that will let me, from a service running in Session 0, spawn processes in other sessions, such as on the logon screen, or the logged in user's session. This will allow me to access the GPU from a service.
Long Poll support added.
Now supports failover pools.
RELASE
https://github.com/wasabii/BitMaker/downloads
Edit BitMaker.Console.exe.config to set your pool url, for now.
Jump to: