Hi ck, you uploaded this file, here?: m.majorgeeks.com/files/details/cgminer.html
Or was some other people.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 2. (Read 5805198 times)
September 02, 2018, 07:46:10 PM
August 28, 2018, 03:19:24 AM
Hi all,
I have added cgminer support to rig-monitor. Check here: https://bitcointalksearch.org/topic/new-free-rig-monitor-40-alpha-released-2128602
I have added cgminer support to rig-monitor. Check here: https://bitcointalksearch.org/topic/new-free-rig-monitor-40-alpha-released-2128602
August 15, 2018, 12:07:13 AM
I've tagged a new version - 4.11.0 - the first in a while. Apart from numerous small bugfixes, the main new features are the Dragonmint T1 driver and the coinbase decode option. As you're unlikely to use anything but the latter, I've summarised the basic instructions from the README here:
Q: How do I use the --decode function to decode a pool's coinbase?
A: You need to have a bitcoind with server functionality and pass it the
credentials as the first pool in your config, and pass the pool's address that
you wish to decode as the second pool configured. Note the bitcoind NEEDS the
http:// prefix.
e.g.:
./cgminer -o http://localhost:8332 -u user -p pass -o solo.ckpool.org:3333 -u 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ --decode
EDIT: Updated to 4.11.1 for a missing bugfix and included NEWS outlining changelog.
Q: How do I use the --decode function to decode a pool's coinbase?
A: You need to have a bitcoind with server functionality and pass it the
credentials as the first pool in your config, and pass the pool's address that
you wish to decode as the second pool configured. Note the bitcoind NEEDS the
http:// prefix.
e.g.:
./cgminer -o http://localhost:8332 -u user -p pass -o solo.ckpool.org:3333 -u 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ --decode
EDIT: Updated to 4.11.1 for a missing bugfix and included NEWS outlining changelog.
July 18, 2018, 09:08:07 PM
Can anyone confirm this is legit link for windows binary:
http://www.majorgeeks.com/files/details/cgminer.html
There is no legit link for any windows binary any more. The only legit ones were on my website, and antivirus scans falsely tagged them as malware and there was no way to appeal the tag so I've given up on windows binaries entirely and removed them all from my site. Anyone mining today should be mining with linux and most hardware is using a controller device that already runs linux. http://www.majorgeeks.com/files/details/cgminer.html
July 18, 2018, 09:04:49 PM
Can anyone confirm this is legit link for windows binary:
http://www.majorgeeks.com/files/details/cgminer.html
http://www.majorgeeks.com/files/details/cgminer.html
June 12, 2018, 06:43:35 AM
Hi,
did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
It's a linux kernel crash; i.e. an operating system crash. No userspace program should be able to do that so it's not cgminer at fault.did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
Thanks, but I was trying bfgminer and it works so they maybe did some workaround
thanks for explanation
June 12, 2018, 05:20:20 AM
Hi,
did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
It's a linux kernel crash; i.e. an operating system crash. No userspace program should be able to do that so it's not cgminer at fault.did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
Thanks, but I was trying bfgminer and it works so they maybe did some workaround
June 12, 2018, 05:11:37 AM
Hi,
did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
It's a linux kernel crash; i.e. an operating system crash. No userspace program should be able to do that so it's not cgminer at fault.did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
Thanks, but I was trying bfgminer and it works so they maybe did some workaround
June 10, 2018, 05:55:02 PM
Hi,
did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
It's a linux kernel crash; i.e. an operating system crash. No userspace program should be able to do that so it's not cgminer at fault. did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
June 08, 2018, 09:53:00 AM
Hi,
did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
May 29, 2018, 05:13:50 PM
At what point in the mining cycle do new mempool transactions typically get added to the Merkle tree of a candidate block and what variables govern this?
Is a mempool snapshot taken once and then mined until a winner arrives or is found?
Or does cgminer continually add new transactions to the existing block opportunistically? If so is there any impact on the hashing speed due to the re-computation of the header? Maybe there isn't since the CPU can do that, while the ASIC does the mining? I suppose that would be an opportunity to reset the Nonce too.
Thanks for any insights, I am not a miner, but interested in the effect on the mempool and chances of a new TX getting into the next block.
The mempool snapshot is done at the server level in the bitcoin daemon which is handed off to the mining pool, about once per minute so they're always up to date. Cgminer is at the client end and does not do any of this unless you are solo mining with it. Is a mempool snapshot taken once and then mined until a winner arrives or is found?
Or does cgminer continually add new transactions to the existing block opportunistically? If so is there any impact on the hashing speed due to the re-computation of the header? Maybe there isn't since the CPU can do that, while the ASIC does the mining? I suppose that would be an opportunity to reset the Nonce too.
Thanks for any insights, I am not a miner, but interested in the effect on the mempool and chances of a new TX getting into the next block.
May 29, 2018, 11:59:34 AM
At what point in the mining cycle do new mempool transactions typically get added to the Merkle tree of a candidate block and what variables govern this?
Is a mempool snapshot taken once and then mined until a winner arrives or is found?
Or does cgminer continually add new transactions to the existing block opportunistically? If so is there any impact on the hashing speed due to the re-computation of the header? Maybe there isn't since the CPU can do that, while the ASIC does the mining? I suppose that would be an opportunity to reset the Nonce too.
Thanks for any insights, I am not a miner, but interested in the effect on the mempool and chances of a new TX getting into the next block.
Is a mempool snapshot taken once and then mined until a winner arrives or is found?
Or does cgminer continually add new transactions to the existing block opportunistically? If so is there any impact on the hashing speed due to the re-computation of the header? Maybe there isn't since the CPU can do that, while the ASIC does the mining? I suppose that would be an opportunity to reset the Nonce too.
Thanks for any insights, I am not a miner, but interested in the effect on the mempool and chances of a new TX getting into the next block.
May 22, 2018, 07:11:57 PM
this is only for mining BTC ?
is there another algos ?
i have custom FPGA boards and i can connect to my FPGA with cgminer by using usb com port
it is minnig but very low hashrate so i need to mine different algos.
Yesis there another algos ?
i have custom FPGA boards and i can connect to my FPGA with cgminer by using usb com port
it is minnig but very low hashrate so i need to mine different algos.
No.
Then you're asking for help in the wrong place.
May 16, 2018, 05:11:47 AM
Why is the API in Restricted mode?
You choose the settings for the API. Not sure what you're talking about but my guess is you're talking about some hardware specific implementation of cgminer; that's nothing to do with me. April 30, 2018, 06:28:45 AM
Dragonmint T1 driver and asicboost rolling support for cgminer is now part of the public master cgminer code.
https://github.com/ckolivas/cgminer/commit/e7128f35d9b5ba816113e7f959aba47c6a870a3b
https://github.com/ckolivas/cgminer/commit/e7128f35d9b5ba816113e7f959aba47c6a870a3b
March 29, 2018, 04:51:37 PM
Hi cgminer devs,
someone sells modded firmware for antminer d3 on ebay... as far as i know this contains modified cgminer and your source are under GPLv3.
https://www.ebay.de/itm/AntMiner-D3-Custom-Firmware-50-Stromkosten/162961717033?hash=item25f1467729:g:XuIAAOSwihpataEA
best regards
someone sells modded firmware for antminer d3 on ebay... as far as i know this contains modified cgminer and your source are under GPLv3.
https://www.ebay.de/itm/AntMiner-D3-Custom-Firmware-50-Stromkosten/162961717033?hash=item25f1467729:g:XuIAAOSwihpataEA
best regards
February 24, 2018, 07:53:51 PM
Thanks ck!
My question was geared more towards how the version is placed into header_bin, pool->header, and eventually work->data prior to being hashed.
The older block you listed gets hashed as: https://blockchain.info/block/00000000000000001ed61d4b7dd337c8eb1de0f21a0bd310a8733fb35f21991cformat=hex
02000000ea7ee4542a0d7496954302e67b99a4d1a3d1c2724f8ddb1a00000000000000007d28ed3cb6e06dc df8267afaa908999d48f2d4deba94b4e344c3e126a3c8b00b174e1f54e9db2418e5bc702
The newer as (and current blocks): https://blockchain.info/block/00000000000000000077140243064000ba35b22d3e2440e936a722b90cd09365?format=hex
00000020633a9073c5b1a5f32afefa4c1116c5bb9c593dfa419812000000000000000000515b81eeca6c575 93c90264ee1a1cb581fc3b7052e8adc23ec16db9917cf828bd33d575ac19100184dbccd28
Current blocks manually double sha256 hashed give correct results with the second format.
I guess I am not seeing in the code where the version is flipped after it is placed in as "20000000" prior to being hashed.
Thanks again for your help!
-Ken
My question was geared more towards how the version is placed into header_bin, pool->header, and eventually work->data prior to being hashed.
The older block you listed gets hashed as: https://blockchain.info/block/00000000000000001ed61d4b7dd337c8eb1de0f21a0bd310a8733fb35f21991cformat=hex
02000000ea7ee4542a0d7496954302e67b99a4d1a3d1c2724f8ddb1a00000000000000007d28ed3cb6e06dc df8267afaa908999d48f2d4deba94b4e344c3e126a3c8b00b174e1f54e9db2418e5bc702
The newer as (and current blocks): https://blockchain.info/block/00000000000000000077140243064000ba35b22d3e2440e936a722b90cd09365?format=hex
00000020633a9073c5b1a5f32afefa4c1116c5bb9c593dfa419812000000000000000000515b81eeca6c575 93c90264ee1a1cb581fc3b7052e8adc23ec16db9917cf828bd33d575ac19100184dbccd28
Current blocks manually double sha256 hashed give correct results with the second format.
I guess I am not seeing in the code where the version is flipped after it is placed in as "20000000" prior to being hashed.
Thanks again for your help!
-Ken
Take a look at some blocks to see what version looks like these days, eg:
https://btc.com/00000000000000000077140243064000ba35b22d3e2440e936a722b90cd09365
Compare with older blocks, eg:
https://btc.com/00000000000000001ed61d4b7dd337c8eb1de0f21a0bd310a8733fb35f21991c
https://btc.com/00000000000000000077140243064000ba35b22d3e2440e936a722b90cd09365
Compare with older blocks, eg:
https://btc.com/00000000000000001ed61d4b7dd337c8eb1de0f21a0bd310a8733fb35f21991c
February 24, 2018, 01:34:59 AM
I hope this isn't a dumb question...
Going through some of my debug logs, I noticed that the generated stratum header has the version like this:
[2018-02-15 23:08:23.772] Generated stratum header 20000000ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000
Shouldn't it be like this?:
[2018-02-15 23:08:23.772] Generated stratum header 00000020ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000
I didn't see anywhere in the code where the bbversion was reversed. Unless I missed it. I did see some previous posts from way back where the block version is shown in the logs like my second example.
The version gets put in the header_bin as in the first example, not reversed. Raw block headers have the version reversed and when test hashed, produce the correct hashes.
Thanks,
-Ken
Take a look at some blocks to see what version looks like these days, eg:Going through some of my debug logs, I noticed that the generated stratum header has the version like this:
[2018-02-15 23:08:23.772] Generated stratum header 20000000ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000
Shouldn't it be like this?:
[2018-02-15 23:08:23.772] Generated stratum header 00000020ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000
I didn't see anywhere in the code where the bbversion was reversed. Unless I missed it. I did see some previous posts from way back where the block version is shown in the logs like my second example.
The version gets put in the header_bin as in the first example, not reversed. Raw block headers have the version reversed and when test hashed, produce the correct hashes.
Thanks,
-Ken
https://btc.com/00000000000000000077140243064000ba35b22d3e2440e936a722b90cd09365
Compare with older blocks, eg:
https://btc.com/00000000000000001ed61d4b7dd337c8eb1de0f21a0bd310a8733fb35f21991c
February 22, 2018, 07:52:17 PM
I hope this isn't a dumb question...
Going through some of my debug logs, I noticed that the generated stratum header has the version like this:
[2018-02-15 23:08:23.772] Generated stratum header 20000000ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000
Shouldn't it be like this?:
[2018-02-15 23:08:23.772] Generated stratum header 00000020ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000
I didn't see anywhere in the code where the bbversion was reversed. Unless I missed it. I did see some previous posts from way back where the block version is shown in the logs like my second example.
The version gets put in the header_bin as in the first example, not reversed. Raw block headers have the version reversed and when test hashed, produce the correct hashes.
Thanks,
-Ken
Going through some of my debug logs, I noticed that the generated stratum header has the version like this:
[2018-02-15 23:08:23.772] Generated stratum header 20000000ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000
Shouldn't it be like this?:
[2018-02-15 23:08:23.772] Generated stratum header 00000020ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000
I didn't see anywhere in the code where the bbversion was reversed. Unless I missed it. I did see some previous posts from way back where the block version is shown in the logs like my second example.
The version gets put in the header_bin as in the first example, not reversed. Raw block headers have the version reversed and when test hashed, produce the correct hashes.
Thanks,
-Ken
February 20, 2018, 09:11:20 AM
I installed my own bitcoin mining pool using unomp (ubuntu VM) and I now try to run cgminer to test GPU mining on it.
I use CGMiner 3.7.2 and I have a NVIDIA 1050 TI
Unsupported. Only the current version and bitcoin mining with ASICs is supported here. I use CGMiner 3.7.2 and I have a NVIDIA 1050 TI
Jump to: