Topic: [Idea] How to approach a MultiAlgo miner (Read 1049 times)

I think that would practically be a modular/scriptable stratum proxy.

An intelligent stratum proxy could do this (if stratum protocol had the algo param) and a lot more. Maybe it would be possible to use it to merged mine merged minables while mining on a regular pool.

The same proxy could maybe be used on pool side to handle coin switches.

that isnt a bad idea. i could do it in python. problem is windows support. ive not yet mastered it

This is a good idea, so like... A miner aggregator that handles the offloading of jobs based on detected algo?

That would make it incredibly modular.

Can't the miner determine the algo by trying all it knows on the first block it gets? I don't know how it works.

With the coming scrypt asics not the gridseeds, but the new better multi mh units scrypt it self well go on as sha256 does..An asic only deal.

So if the Sgminer devs wish to abandon GPUS as the cgminer devs did so be it.

As of right now having to run a separate miner for each algo and having now like 20 forks for each.

1 "version" that can do SHA asics, scrypt asics, fpgas, GPUs, and CPUs is what is needed can not say it can not be done cudaminer already does this to some extent.  Multipools or not 1 instance of XYZ miner with the ability to perhaps setup multiple diff algo pools and allow said software to change pools + algos even semi seamlessly.

This can and does benefit multipools alot for those who wish to go that route but more so benefiting the miners who dont like running 20 instances of cg/sgminer on each rig.

I'll contribute what I can but most of it is beyond my skill set.

as the current maintainer of the MPOS recommended stratum fork id be happy and willing to add support for algo switching

Sgminer devs have basically said that sgminer = scrypt cgminer. They do not want to add other algorithms. Scrypt-n fits in since it's scrypt.

So they are probably not going to chip in.

sgminer appears to already be heading in this direction.  It has some of the foot work done already.  Namely, it supports BOTH scrypt and scrypt-N, at least in the latest git repo.  I don't think the latest release supports it.  Though it requires load time parameters to be set to specify which algorithm you wish to use, and in scrypt-N's case, that the current nfactor should be.  I don't think there is any sha3/keccak support or any other algorithm in there yet, but clearly they see value in other algorithms.

As much as I want to say this makes sense to be done... the reality is its really only going to benefit the multipools.  The people actually developing coins and running pools for those coins etc will not have any interest at all in this.  Multipools in general are not liked by coin devs.  You could make an argument that somebody could make a coin that changes algorithm frequently if this were supported... but why would anybody really want to do that.  Otherwise the only benefit to be had by individual coins is changing n-factor in scrypt-N during runtime.

While I'm not going to claim to know any of these pieces of software inside and out, I have a pretty basic understanding of it all.

In my view, this is what would need to happen:

• stratum-mining
  • stratum protocol needs to be modify to allow it to carry extra configuration parameters regarding the jobs its handing out.  IE. hash algorithm, and any extra associated parameters with each algorithm.  This should be done in an extensible way that would allow new hashing algorithms to be added without the need to modify the protocol again if a new hash algorithm starts being used.  The real bonus of this in my opinion... it will pave the way for an scrypt-N coin to be able to change the n-factor on the fly instead of having pre-determined points in times that the nfactor changes and instead do something like base it on current network difficulty.
• sgminer/cgminer/whateverminer
  • is going to need some pretty fundamental changes.  Currently setting the algorithm and parameters is done entirely at load time.  This would need to be redone to restart the GPU threads with different algorithms during runtime.
  • Will also need to be modified to allow specifying configuration parameters for each hashing algorithm.  IE. on scrypt i want to use engine clock X, TC Y, Intensity Z, but on scrypt-N i want blah blah blah

None of this is really a big deal, with exception of the first point for the miners... that could be a bit of a challenge.  Like I said though, I don't know the code inside and out, it might be alot easier than I'd expect.

Ahmed! That would be fantastic. Thats one part of the puzzle right there.

i like the idea. to switch algo's stratum could just pass:

{'mining.algo': '}

it wouldnt be difficult to change either i could do it

obligatory reserved

First off, this is just an idea session. I dont claim this is perfect. I just want to throw these ideas out in the hopes that it sparks something. If i had the skill to code this myself, I would. This is self moderated to stymie trolling. Please bring your arguments and counter arguments, but lets be civil.  

The Problem:
There is a serious need for a single miner that can hash multiple algorithms. There are many forks of the incumbent cgminer and we need to have a single miner that can support various algos in a stable and scalable way. (relevant xkcd https://xkcd.com/927/)

Whats in it for me?:
You will be able to take your favorite/current mining OS (Bamt, linux proper, smos, potato, windows) and replace your existing "cgminer" and easily be able to move between coins/algos/pools at a whim.
*controversy* Multipools can now take advantage of switching algo's and coins to further rape and pillage the CryptoCurrency landscape. You may or may not be in favor of this, so let try to not turn this into an argument about multipools.

There is already x project in the works so stfu:
Great! I sure hope so, but it seems like noone has quite done it to the caliber of a static cgminer deployment. The name of the game here is stability and scalability. If anyone else is already close to having this to market then this post just fades out. But if they are stuck, or worse yet, nobody has really gotten anywhere, then maybe this will turn into a great brain storming session.

The approach:
Hopefully you still care at this point, cause this is where we need a community effort!

I do not claim to have an indepth understanding of C, opencl, GPU architecture, why BCX acts like that, or ckolivas' favorite breakfast cereal... but i did compile sgminer to to do keccak one time and i thought that was pretty damn cool.

What needs to be done:

• Create a single opencl instruction set that contains all algorithms in a way that they are only parsed when called by the active algo. Something like functions in php (yea i know, php is the only lang i know)
• Modify Stratum to support passing a flag or parameter to the client indicating an algo change. Something the VARDIFF mechanism already in use does
• Use a single config file to specify what algos are enabled on what pools, and what the devices config should look like for each algorithm. http://pastebin.com/UrgTirjr

How does that help?:
It gives us a way to cleanly replace existing forks, have a single instance of cgminer running at a time, not require GPUs to spin down/up on changes as drastically, not have to restart the whole miner process, and allow new algos to be easily added in by creating the necessary instruction set in the main .cl.

Well shit, how do we do that?:

Fucked if i know man, I told you... If i could do it myself I would. I dont even know if it can work this way.... I'm just throwing out ideas, hoping the community takes hold and something comes of it.

Discuss...