Topic: An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only) - page 21. (Read 1958546 times)

It is certainly possible, but it would be a bit pointless in my opinion. If a server provides a getblocktemplate method but no submitblock method, then it is violating the official specifications.

Interesting... :-( Is it possible to test availability of submitblock method by a submit of random data after cpuminer start?

Apparently your daemon does not implement the submitblock method, even though it is part of the non-optional sections of BIP 22.

As a matter of fact, I've mined several blocks on the Litecoin testnet, so I know that the GBT implementation of 2.4 is not (entirely) broken.

I am sorry to write this but GBT submit doesn't work. I haven't found any new block from the time I run cpuminer 2.4. When I use "--no-gbt", blocks are found and accepted...

I use powercoin (https://github.com/Powercoin/Powercoin) to test it. Powercoin is dead coin with very low difficulty, good to test solo mining. Powercoin code was not updated for a while so it could be a source of problem but I assume code is good enough to replicate this problem.

When cpuminer tries to submit GBT block, block is rejected with 404 error.
I tried to mine with "--coinbase-addr=xx" and "--coinbase-addr=xx --coinbase-sig=yy" and blocks are rejected in both cases.

When I mine with "--no-gbt", blocks are accepted

Example of "rejected" GBT block:

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

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

Thanks, will look into it.

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.

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

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.

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

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).

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.)

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


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

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.

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.

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.

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.

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

4% increase, nice 

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

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)?

No, it is not possible.

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).

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

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...

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.

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...

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.

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.