Bitcoin Forum
December 06, 2016, 06:04:37 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 [51] 52 53 54 55 56 57 58 59 60 »
  Print  
Author Topic: An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only)  (Read 1529563 times)
PSL
Member
**
Offline Offline

Activity: 113


View Profile
May 21, 2014, 11:18:42 AM
 #1001

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)...
1481047477
Hero Member
*
Offline Offline

Posts: 1481047477

View Profile Personal Message (Offline)

Ignore
1481047477
Reply with quote  #2

1481047477
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481047477
Hero Member
*
Offline Offline

Posts: 1481047477

View Profile Personal Message (Offline)

Ignore
1481047477
Reply with quote  #2

1481047477
Report to moderator
1481047477
Hero Member
*
Offline Offline

Posts: 1481047477

View Profile Personal Message (Offline)

Ignore
1481047477
Reply with quote  #2

1481047477
Report to moderator
1481047477
Hero Member
*
Offline Offline

Posts: 1481047477

View Profile Personal Message (Offline)

Ignore
1481047477
Reply with quote  #2

1481047477
Report to moderator
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 21, 2014, 11:38:10 AM
 #1002

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.

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

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
PSL
Member
**
Offline Offline

Activity: 113


View Profile
May 21, 2014, 12:25:03 PM
 #1003

Quote
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
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 21, 2014, 12:30:27 PM
 #1004

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.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
PSL
Member
**
Offline Offline

Activity: 113


View Profile
May 21, 2014, 12:55:00 PM
 #1005

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
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 21, 2014, 01:18:02 PM
 #1006

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.

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

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
PSL
Member
**
Offline Offline

Activity: 113


View Profile
May 21, 2014, 01:26:11 PM
 #1007

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
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 21, 2014, 01:31:48 PM
 #1008

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.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
ficklepickle
Member
**
Offline Offline

Activity: 70


View Profile WWW
May 21, 2014, 11:25:18 PM
 #1009

4% increase, nice  Cool

fulanomengano
Newbie
*
Offline Offline

Activity: 28


View Profile
May 22, 2014, 07:04:04 AM
 #1010

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

BTC: 1Fd8n26auEzWQSqmf4HU1xyiEpPoJmhXuS
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 22, 2014, 07:56:56 AM
 #1011

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.

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

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 22, 2014, 12:49:18 PM
 #1012

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.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 22, 2014, 01:41:47 PM
 #1013

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

pooler-cpuminer-2.2.3-win64 works fine.
Quote
[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.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
fulanomengano
Newbie
*
Offline Offline

Activity: 28


View Profile
May 23, 2014, 06:16:53 PM
 #1014

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

Quote
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


BTC: 1Fd8n26auEzWQSqmf4HU1xyiEpPoJmhXuS
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 23, 2014, 08:04:58 PM
 #1015

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

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
fulanomengano
Newbie
*
Offline Offline

Activity: 28


View Profile
May 23, 2014, 11:23:58 PM
 #1016

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

BTC: 1Fd8n26auEzWQSqmf4HU1xyiEpPoJmhXuS
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 24, 2014, 08:25:46 AM
 #1017

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.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
PSL
Member
**
Offline Offline

Activity: 113


View Profile
May 24, 2014, 11:46:25 AM
 #1018

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.
Code:
[2014-05-24 10:42:20] HTTP request failed: The requested URL returned error: 404
[2014-05-24 10:42:20] submit_upstream_work json_rpc_call failed
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
Code:
[2014-05-24 11:02:52] accepted: 1/1 (100.00%), 4.83 khash/s (yay!!!)

Example of "rejected" GBT block:
Code:
[2014-05-24 10:57:55] JSON protocol request:
{"method": "submitblock", "params": ["01000000e65ab64270079fbca476b71bfce63f647b
9fd6ad518606cac7fc1399f0b1602f8f6bd269a664a8b6b0c0db263ee954192316678c33d0c1f9a0
0ee00f1842204f317b805350d9011ea0000de5010100000001000000000000000000000000000000
0000000000000000000000000000000000ffffffff140305c9020f3564656162353063062f503253
482fffffffff0100286bee000000001976a914f650f1ee4beb5f988696abddb3150a9f4bfdb93288
ac00000000"], "id":1}

* Re-using existing connection! (#0) with host powerminer
* Connected to powerminer (54.87.211.179) port 9863 (#0)
* Server auth using Basic with user 'PWC'
> POST / HTTP/1.1
Authorization: Basic TU0uUFdDOjlKUVh1VFVjNmVrNzRGV2EyeUVYN1JIYzg1ckhEV0M3Wkp3bWpCdjdwU3Ni
Host: powerminer:9863
Accept-Encoding: deflate, gzip
Content-Type: application/json
Content-Length: 423
User-Agent: cpuminer/2.4
X-Mining-Extensions: midstate

* The requested URL returned error: 404
* Closing connection #0
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
May 24, 2014, 02:36:44 PM
 #1019

When cpuminer tries to submit GBT block, block is rejected with 404 error.
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.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
PSL
Member
**
Offline Offline

Activity: 113


View Profile
May 24, 2014, 04:38:03 PM
 #1020

When cpuminer tries to submit GBT block, block is rejected with 404 error.
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.

Interesting... :-( Is it possible to test availability of submitblock method by a submit of random data after cpuminer start?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 [51] 52 53 54 55 56 57 58 59 60 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!