An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only)

[Oldminer]

Loving cpuminer 

[1713568935]

1713568935

[1713568935]

1713568935

[Netscout]

Loving cpuminer 

https://i.imgur.com/5CnWrb8.png

2.7MH/s with 800Mhz ... What do you mine and with what do you mine?

stratum+tcp://us-east2.multipool.us:7777 = scrypt

[pooler]

Version 2.4

• Support for getblocktemplate (GBT, BIP 22). With getwork deprecated and soon to be removed from Bitcoin, it was important to get this implemented, especially for testing solo mining. The getblocktemplate method is now used by default for protocol HTTP, but the miner should automatically switch to getwork if the newer method is not available. To force the miner to use getwork, a --no-gbt option is provided.
• It is now possible to tunnel Stratum through an HTTP proxy.
• A --no-redirect option has been added, which makes the miner ignore redirection/reconnection requests coming from the server.
• Startup error messages are now more descriptive.
• The output of the --version option has been expanded to include additional build information.

The source code is, as always, available at GitHub. Source tarball and binaries are available at Sourceforge.

[PSL]

Version 2.4

• Support for getblocktemplate (GBT, BIP 22). With getwork deprecated and soon to be removed from Bitcoin, it was important to get this implemented, especially for testing solo mining. The getblocktemplate method is now used by default for protocol HTTP, but the miner should automatically switch to getwork if the newer method is not available. To force the miner to use getwork, a --no-gbt option is provided.

I found that for solo mining with cpuminer V1.4 I have to extend command line with parameter
--no-gbt or --coinbase-addr otherwise it will not connect to the "coin server":

Code:

[2014-05-21 13:05:06] No payout address provided
[2014-05-21 13:05:06] json_rpc_call failed, retry after 30 seconds

BTW, I think this is a cpuminer bug that it doesn't try to switch to getwork protocol and stays in never-ending loop waiting for a miracle...

I added --coinbase-addr because I think it can address a problem with wallet design, where it is not possible to export default key (at least I failed to find how to do it) and I have to keep backup of binary wallet that is far from perfect.

I test it at the moment, no block was found so far and that could be an indicator that something is wrong... Maybe I have only bad luck...

I found bfgminer notice, that when several clients are connected to the same "coin server" and are mining to the same address, than parameter --coinbase-sig has to be added

https://github.com/luke-jr/bfgminer, section SOLO MINING.

Is it true that --coinbase-sig with unique parameter has to be added when more clients are connected with the same address?? So far, I just configured all my clients with the same --coinbase-addr address but I am not sure if this is good idea because it is possible that they work on the same units and my computing power is reduces compared to configuration with --no-gbt (operation mode of older cpuminer)...

[pooler]

I found that for solo mining with cpuminer V2.4 I have to extend command line with parameter --no-gbt or --coinbase-addr otherwhise it will not connect to the "coin server".

That is correct. If you pass --no-gbt the miner will use the legacy getwork method, so all the block building is handled by the server. If on the other hand you want to use getblocktemplate for solo mining, then you have to provide a payout address.

I found bfgminer notice, that when several clients are connected to the same "coin server" and are mining to the same address, then parameter --coinbase-sig has to be added

https://github.com/luke-jr/bfgminer, section SOLO MINING.

Is it true that --coinbase-sig with unique parameter has to be added when more clients are connected with the same address?

Yes. If you intend to have multiple miners mining solo to the same address, each of them should specify a different signature. Alternatively, you can specify a different address for each miner.

[PSL]

I found bfgminer notice, that when several clients are connected to the same "coin server" and are mining to the same address, then parameter --coinbase-sig has to be added

https://github.com/luke-jr/bfgminer, section SOLO MINING.

Is it true that --coinbase-sig with unique parameter has to be added when more clients are connected with the same address?

Yes. If you intend to have multiple miners mining solo to the same address, each of them should specify a different signature. Alternatively, you can specify a different address for each miner.

Thank you for confirmation. That is bad news... I have a problem with a signature, it will be put to blockchain and everyone can see it. Is there other possibility to mine with the same address but without creating public message in the blockchain? Could be this addressed with new parameter that will work like signature but it will not be stored to blockchain? It will be just a local ID for mining client, I can use client hostname or IP address or something like that...

[pooler]

If you intend to have multiple miners mining solo to the same address, each of them should specify a different signature. Alternatively, you can specify a different address for each miner.

Thank you for confirmation. That is bad news... I have a problem with a signature, it will be put to blockchain and everyone can see it. Is there other possibility to mine with the same address but without creating public message in the blockchain? Could be this addressed with new parameter that will work like signature but it will not be stored to blockchain? It will be just a local ID for mining client...

I don't see the problem. The "signature" can be any string you like. For example, if you have three miners, you can use signatures "1", "2" and "3". Signatures don't have to be globally unique, they just need to be different for all miners using the same payout address and mining at the same time.

[PSL]

I don't see the problem. The "signature" can be any string you like. For example, if you have three miners, you can use signatures "1", "2" and "3". Signatures don't have to be globally unique, they just need to be different for all miners using the same payout address and mining at the same time.

OK, I don't like the idea to publish ballast that is not important but I can mine with parameters like these:

Code:

--coinbase-addr=$CBADDRESS --coinbase-sig=$(hostname | sha256sum | cut -c1-64)

Anyway, is it technically possible to add a parameter that will work like signature but will be used only by miner and will not be published in the block-chain as signature? Block-chain, it is huge data structure replicated to millions of disks and every useless ballast there consumes significant disk space...

[pooler]

Anyway, is it technically possible, to add a parameter that will work like signature but will be used only by miner and will not be published in the block-chain as signature?

No, it is not possible.

Block-chain, it is huge data structure replicated to millions of disks and every useless ballast there consumes significant disk space...

This is not "ballast". It is something necessary, and actually very small when you consider the size of a block.
The same mechanism is used by poolservers to distribute different work to miners, and even by the old getwork method to ensure that every requested work be unique. And all the extra nonces have always ended up in the block chain.

The truth is, if your signature is short, your coinbases will be smaller than those produced by getwork. Thus, if you are concerned about block size, using a single-byte signature is definitely the best solution (assuming you don't have more than 256 miners).

[PSL]

I have the last point related to signatures that I miss. What signature is used in the case when it is not specified at cpuminer command line (--coinbase-sig parameter is missing)?

[pooler]

What signature is used in the case when it is not specified at cpuminer command line (--coinbase-sig parameter is missing)?

No particular signature is included in the coinbase if you don't specify one. Just the block height as per BIP 34.

[ficklepickle]

4% increase, nice 

[fulanomengano]

It does seems to be faster. Don't have hard #s yet, but I estimate 5-10% faster.

Any chance of adding more options and features? Like API, logging, dynamic screen info (a la BFGMiner or cpuminer-gc3355).

FM

[pooler]

It does seems to be faster. Don't have hard #s yet, but I estimate 5-10% faster.

The hashing code hasn't changed since version 2.3.2, as you can see for yourself from the commit history. Any hash rate variation you might see is purely accidental.

Any chance of adding more options and features? Like API, logging, dynamic screen info (a la BFGMiner or cpuminer-gc3355).

I'm not sure what you mean by "logging", given that cpuminer has always produced a log.
Regarding APIs and integrated graphical interfaces, they will probably never happen, as I don't think they conform to the KISS philosophy.

[pooler]

Code:

Stratum requested work restart

Why?

Because your pool's server sent you new work and asked you to start working on it immediately.
This is usually normal and completely harmless. If you think that a work restart means that your past hashing is now "lost" then you are committing a fallacy, as there is no "progress" when you mine.

[pooler]

For me, looks to be, the pool is not picking up 2.4 shares.

pooler-cpuminer-2.2.3-win64 works fine.

[2014-05-22 08:33:03] Stratum detected new block

I see no difference between the log you just posted above and the one you posted before. The message "Stratum detected new block" was changed to "Stratum requested work restart" in version 2.4, as that's a more correct description of what is happening.
Neither of the two logs you've posted so far shows any accepted share.

[fulanomengano]

It does seems to be faster. Don't have hard #s yet, but I estimate 5-10% faster.

The hashing code hasn't changed since version 2.3.2, as you can see for yourself from the commit history. Any hash rate variation you might see is purely accidental.

Ok, thanks for the clarification. Maybe I got too exited :-).

Any chance of adding more options and features? Like API, logging, dynamic screen info (a la BFGMiner or cpuminer-gc3355).

I'm not sure what you mean by "logging", given that cpuminer has always produced a log.
Regarding APIs and integrated graphical interfaces, they will probably never happen, as I don't think they conform to the KISS philosophy.

I agree with KISS. But that means not adding things when they are not needed. Of course, what's needed varies a lot from person to person. Let me clarify what I meant in my previous post.

Re API, I think it could be quite useful when you want to manage several PCs remotely. I currently use a combination of proxy (to switch pools), scripts (to restart the miner with # of threads = 50% of cores when someone is going to use that computer) and manual log review to monitor the status. An API that could let you check the status, switch pools and # of threads would be ideal for that.

Re logging I'm using the 2 >> logfile.log (Windows) at the end of the line to log to a file. This creates the log file but does not output anything to screen. A -L option like BFGMiner allows you to write to a log file while still seeing the output on the screen, which is sometimes useful. Also a --sharelog option allows you to output the accepted shares on a different file for easier reviewing.

By dynamic screen I didn't mean a GUI. I'm not sure if you can call what the other miners have a "graphical interface", but I was thinking more like the options to manage pools and processors without having to restart the miner with different parameters. An API could solve this issues too.

Maybe, once I mine some coins, I can bribe you include some of these :-).

BTW, thanks for this great miner!


FM

[pooler]

Re API, I think it could be quite useful when you want to manage several PCs remotely. I currently use a combination of proxy (to switch pools), scripts (to restart the miner with # of threads = 50% of cores when someone is going to use that computer) and manual log review to monitor the status. An API that could let you check the status, switch pools and # of threads would be ideal for that.

I think the main problem with adding an API is that it would greatly complicate the code base. Luckily cpuminer starts up very quickly, so a wrapper script can usually do the job pretty well.

Re logging I'm using the 2 >> logfile.log (Windows) at the end of the line to log to a file. This creates the log file but does not output anything to screen.

That's what tee is for. Or you could tail -f the file where the output is stored.

Also a --sharelog option allows you to output the accepted shares on a different file for easier reviewing.

This could indeed be useful. I will think about it, but keep in mind that the changes required to implement this properly are nontrivial (cpuminer does not currently keep track of submitted shares).

By dynamic screen I didn't mean a GUI. I'm not sure if you can call what the other miners have a "graphical interface", but I was thinking more like the options to manage pools and processors without having to restart the miner with different parameters. An API could solve this issues too.

Personally, I think cpuminer was never designed to be interactive... and I actually like it the way it is, because I value simplicity. But then again, this is probably a matter of personal taste, just like the old vi-vs-Emacs debate.

(By the way, I just learned that there's a name for the kind of user interface that cgminer sports: TUI, i.e. Textual User Interface.)

[fulanomengano]

I think the main problem with adding an API is that it would greatly complicate the code base. Luckily cpuminer starts up very quickly, so a wrapper script can usually do the job pretty well.

True, will look into something like that. It will probably be Java, my C skills are beyond rusty.

That's what tee is for. Or you could tail -f the file where the output is stored.

Thanks, will look into it.

This could indeed be useful. I will think about it, but keep in mind that the changes required to implement this properly are nontrivial (cpuminer does not currently keep track of submitted shares).

I think a simple append of the same line that goes to standard output (e.g. timestamp accepted: X/X (XX.XX%), XX.XX khash/s (yay!!!)) to a separate file will be perfect (at least for what I'm trying to keep track). Any other information related to the specific share could be a bonus for some.

Personally, I think cpuminer was never designed to be interactive... and I actually like it the way it is, because I value simplicity. But then again, this is probably a matter of personal taste, just like the old vi-vs-Emacs debate.

(By the way, I just learned that there's a name for the kind of user interface that cgminer sports: TUI, i.e. Textual User Interface.)

Fair enough. You got your tidbit of information for today :-).

Thanks again. And I wish I would have stayed current with my C programming, would love to peek on the code and help a little.

FM

[pooler]

I think a simple append of the same line that goes to standard output (e.g. timestamp accepted: X/X (XX.XX%), XX.XX khash/s (yay!!!)) to a separate file will be perfect (at least for what I'm trying to keep track). Any other information related to the specific share could be a bonus for some.

If that's all you need then you could simply grep the output stream or the file where you store the log.