Bitcoin Forum
December 09, 2016, 06:06:20 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 [735] 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4824275 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
JoseSan
Member
**
Offline Offline

Activity: 86


View Profile
March 14, 2014, 06:22:03 PM
 #14681

   "scrypt": true,

If you're running new bitcoin ASICS (Gridseed) then you shouldn't have this in there.

If you're actually trying to scrypt mine, watch out, this forum is meant for new cgminer development and troubleshooting. General troubleshooting of old cgminer versions should be asked elsewhere. There's nothing wrong with your config if you run with an older version of cgminer (<3.6 or something).

Yes running cgminer 3.72 and scrypt mining with gridseed 5-chip devices.

I should clarify that although there's nothing *wrong*, it wont work. You *cannot* use cgminer for script mining with a Gridseed. Script mining with a Gridseed device requires some voodoo that does not concern this forum thread. Good day.
1481263580
Hero Member
*
Offline Offline

Posts: 1481263580

View Profile Personal Message (Offline)

Ignore
1481263580
Reply with quote  #2

1481263580
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 14, 2014, 08:19:04 PM
 #14682

What is wrong with my config? Cgminer says Start cgminer with -T to see what failed to load but when I do that, I don't see any errors..
    "gridseed-options": {
    "scrypt": true,

I'm using the cgminer with gridseed support, I have one main issue which is really annoying can you tell me if it's fixed and which version it's fixed on. The problem is that I have to unplug the USB for my gridseed before cgminer starts, once cgminer has started only then I can plug the USB in otherwise the cgminer just freezes or crashes. If I'm accessing the rig remotely and I need to restart the windows computer then I'm stuck as some one physically needs to be at the rig.
Official cgminer contains no gridseed support so you have to seek support from gridseed or whoever is maintaining the cgminer fork with gridseed support.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 15, 2014, 09:09:22 PM
 #14683

Well, I think I may have used an inaccurate phrase in "not quite stable".

It seems to run and doesn't crash.  But it does turn off several erupters on both machines I use, erupters that run just fine on 3.8.4 and 3.11.0.
Any idea what the message is when they're turned off? Is it the not giving valid hashes for greater than X seconds one?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
March 15, 2014, 09:30:11 PM
 #14684

Well, I think I may have used an inaccurate phrase in "not quite stable".

It seems to run and doesn't crash.  But it does turn off several erupters on both machines I use, erupters that run just fine on 3.8.4 and 3.11.0.
Any idea what the message is when they're turned off? Is it the not giving valid hashes for greater than X seconds one?

Don't know.  I'll just notice that a green light is on and when I look they are just listed as off.

I'll fire up 4.1.0 again and see if I can catch it when it turns one off.
Thanks,
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Buchi-88
Legendary
*
Offline Offline

Activity: 1092


My Solo Block: 401934


View Profile
March 17, 2014, 03:06:52 PM
 #14685

Good Day after longer running the new Cgminer i have Problems with the Antminer HW1.2!

Quote
SB device management [P]ool management ettings [D]isplay options [Q]uit
0: ANU 0:                         | OFF   /264.4Th/s | A: 8321 R: 50 HW: 454 WU:  7.0/m
1: ANU 1:                         | OFF   /299.1Mh/s | A: 3601 R: 45 HW: 180 WU:  3.1/m
2: ANU 2:                         | 1.790G/264.4Th/s | A:24883 R:270 HW:1284 WU: 21.1/m
3: ANU 3:                         | 1.820G/264.4Th/s | A:26404 R:522 HW:1298 WU: 20.9/m
4: ANU 4:                         | 1.814G/1.804Gh/s | A:23617 R:417 HW:1327 WU: 21.0/m
5: ANU 5:                         | OFF   /359.8Mh/s | A: 3952 R: 42 HW: 222 WU:  3.5/m
6: ANU 6:                         | OFF   /264.4Th/s | A: 8182 R:178 HW: 467 WU:  7.2/m
--------------------------------------------------------------------------------------------------
 [2014-03-16 23:52:33] ANU 1 failure, disabling!
 [2014-03-17 00:31:46] ANU 5: Device failed to respond to restart
 [2014-03-17 00:31:46] ANU 5 failure, disabling!
 [2014-03-17 04:06:01] ANU 0: Device failed to respond to restart
 [2014-03-17 04:06:01] ANU 0 failure, disabling!
 [2014-03-17 04:06:03] ANU 6: Device failed to respond to restart
 [2014-03-17 04:06:03] ANU 6 failure, disabling!
After a restart the Cgminer all runs good as before???

greets and thanks for help Wink


                ,╓▄▄▄▄▄▄▄▄▄╓                 
            ╓▄█████████████████▄╖           
         ╓▄█████▀▀'▒,,,,,╠'▀▀█████▄,         
       ,▓███▀╜,▄▄███████████▄▄,╙▀████╖       
      ▄███▀ ▄█████▀▀"``╙"▀▀█████▄ ▀███▄     
     ▓███╜╓████▀ ,▄▄█████▄▄, ▀████,╙███▌     
    ▓███`╔███▀ ╓▓███▀▀▀▀▀████╖ ▀███@"███▌   
   ]███▌┌███▌ ▐███         ███▄ ▐███ ▐███,   
   ▐███ ▐███ .███           ███  ███▌ ███▌   
   ▐███ ▐███ '███           ███  ███▌ ███▌   
   ]███@╙███@ ▀██▌        ,▄██▌ ▐███ ▐███`   
    ▓███ ▐███▄ ╙██▀╩     9███╜ ╔███▀,███▌   
     ████,╙███▌               ▓███╜,████     
      ▀███▄ ▀╜                 ▀▀ ▄███▌     
       ╙████▄,                 ╓▄████╜       
         ╙█████▄▄╓,       ,╓▄▄█████▀         
            ▀▀█████████████████▀▀           
                '▀▀▀▀▀▀▀▀▀▀▀'

CloakCoin |  Trustless Anonymous Cryptocurrency |  PoSA3
Forum | Bitcointalk | Twitter | Slack |  Facebook |  VK |  Reddit |  CloakTV |  Instagram |  IRC-Chat |  Faucet
BTCJoe
Jr. Member
*
Offline Offline

Activity: 38


View Profile
March 17, 2014, 04:26:25 PM
 #14686

The new CGMiner also support the new Antminer U2?

I mean yes, only the Heatsink is new?

regards
Try it and let us know Smiley
We don't have any U2's but I think they are the same with just a better heat sink?

Running about 30 sticks of the U2 and --anu-freq 250 runs really well at 1.95 GH-2 GH, tried running it at 275 and HW error goes crazy.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 18, 2014, 11:15:15 AM
 #14687

Good Day after longer running the new Cgminer i have Problems with the Antminer HW1.2!

Code:
[U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit
0: ANU 0:                         | OFF   /264.4Th/s | A: 8321 R: 50 HW: 454 WU:  7.0/m
1: ANU 1:                         | OFF   /299.1Mh/s | A: 3601 R: 45 HW: 180 WU:  3.1/m
2: ANU 2:                         | 1.790G/264.4Th/s | A:24883 R:270 HW:1284 WU: 21.1/m
3: ANU 3:                         | 1.820G/264.4Th/s | A:26404 R:522 HW:1298 WU: 20.9/m
4: ANU 4:                         | 1.814G/1.804Gh/s | A:23617 R:417 HW:1327 WU: 21.0/m
5: ANU 5:                         | OFF   /359.8Mh/s | A: 3952 R: 42 HW: 222 WU:  3.5/m
6: ANU 6:                         | OFF   /264.4Th/s | A: 8182 R:178 HW: 467 WU:  7.2/m
--------------------------------------------------------------------------------------------------
 [2014-03-16 23:52:33] ANU 1 failure, disabling!
 [2014-03-17 00:31:46] ANU 5: Device failed to respond to restart
 [2014-03-17 00:31:46] ANU 5 failure, disabling!
 [2014-03-17 04:06:01] ANU 0: Device failed to respond to restart
 [2014-03-17 04:06:01] ANU 0 failure, disabling!
 [2014-03-17 04:06:03] ANU 6: Device failed to respond to restart
 [2014-03-17 04:06:03] ANU 6 failure, disabling!
After a restart the Cgminer all runs good as before???

greets and thanks for help Wink
Yes it shouldn't disable like that. It should unplug it and allow it to be re-hotplugged. will fix.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 18, 2014, 12:18:32 PM
 #14688

New version: 4.2.0, 18th March 2014

Major feature upgrades - main one being low overhead scaleable solo mining to bitcoind, bugfixes and driver improvements.


Human readable changelog:

- Low overhead ultra-scaleable solo mining to bitcoind. Quote from the documentation update:
Code:
Solo mining can be done efficiently as a single pool entry or a backup to
any other pooled mining and it is recommended everyone have solo mining set up
as their final backup in case all their other pools are DDoSed/down for the
security of the network. To enable solo mining, one must be running a local
bitcoind/bitcoin-qt or have one they have rpc access to. To do this, edit your
bitcoind configuration file (bitcoin.conf) with the following extra lines,
using your choice of username and password:

rpcuser=username
rpcpassword=password

Restart bitcoind, then start cgminer, pointing to the bitcoind and choose a
btc address with the following options, altering to suit their setup:

cgminer -o http://localhost:8332 -u username -p password --btc-address 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ
Note that I have NOT had the pleasure of mining a real solo bitcoin block with this latest code, only on various test networks, so you must accept the risks associated with using it on the real network. It rigidly follows bitcoind rules for transaction processing, updating transactions every 60 seconds and checking for block changes every 0.5 seconds. Be aware this involved a great deal of work and I would not have completed it but for the fact it was partially sponsored. However it was something that was going to be needed at some stage as I think it's mandatory everyone can use solo as their final backup. If you do NOT specify a btc address, you WILL be mining solo for me instead.

- Massive improvements to mining efficiency when using pooled GBT mining.
- Stratum low level bugfixes that may have caused random corruption/crashes.
- Miner.php updates
- Drillbit updates
- Antminer S1 updates
- Fix for repeatedly trying to reset a usb device when it has failed.
- Fix for Icarus  devices (such as antminer U1 or block erupters) being switched off and not restarting.
- More accurate hashrates on cointerra devices, with a more reliable bitmap of working cores and now a count such as:
Code:
Asic0Core0 120:fffefffefffefffefffefffefffefffe
- Per core cointerra hashrates
- Fix for memory leak on hashfast devices.
- Fix for crashes on multiple failed inits on hashfast devices.
- Show what quadrant of a hashfast core has failed if possible
- Fix for hashfast API stats output being invalid json
- Hashfast api stats output names are unique making them more easily parseable
- Inputting URLs without a prefix (such as http:// or stratum+tcp://) will now assume stratum to speed up initial connections.
- On linux we no longer use sysv semaphores to prevent multiple instances of cgminer trying to use the same device, meaning you will no longer run out of semaphore resources or have failures to grab devices on restarting.
- Numerous other low level fixes and improvements.


Full changelog:

- Fix missing htobe16 on windows and meaningless >u32 string warning.
- Software ntime roll for all hashfast devices.
- Silence harmless warning.
- Drop a failed restart icarus device to allow it to be rehotplugged if
possible.
- Work with more than one transaction.
- Kill gbt solo pools that don't respond to the gbt request 5 times
sequentially.
- Fix ser_number for no remaining val byte.
- Create a work item and stage it when updating the gbt solo template to allow
new block detection and restart code to work.
- Test block hash as well as block height when solo mining to ensure we haven't
been mining on an orphan branch.
- Fix transaction processing for gbt solo.
- Encode height using integer varint format.
- Make new block detection message not show in gbt solo from test_work_current
- Add block detection via getblockcount polling in gbt solo and update gbt
template every 60 seconds.
- Iterate over transactions twice to malloc only once when copying all the
transaction data.
- Update solo coinbase regularly and submit as gbt work
- Only show merkle hashes for solo mining in debug mode.
- Set correct flag for solo work.
- Generate gbt solo work emulating stratum work construction.
- Set the diff as a double sdiff from gbt solo data.
- Move swork.diff out of the stratum work section to be shared as sdiff.
- Generate a header bin from gbt solo as per the cached stratum one.
- Store strings similar to stratum's when decoding gbt solo
- Avoid allocing and freeing stratum strings that should be fixed length.
- Run parser through detect_stratum after stratum+tcp:// is force added
- Remove unnecessary header length calculation for stratum header binary and
only binary convert the correct length of the header.
- Share more fields between stratum and gbt
- Share coinbase_len variable b/w stratum and gbt and setup more gbt solo
parameters.
- Generate a valid coinbase and set nonce2offset for gbt solo
- Move scriptsig header bin conversion to setup gbt solo
- Create our own custom scriptsig base.
- Add helper functions for creating script signature templates and beging
building template.
- Do gbt solo decoding under gbt lock.
- Add more gbt variable decoding from gbt solo information.
- Store all the transaction data in binary form when using GBT
- When setting up solo mining, check validity of bitcoin address against
bitcoind
- Make pooled GBT mining use merkle bin optimisations slated for solo mining.
- Abstract out the merkle bin calculation for gbt solo
- Implement efficient merkle tree base from solo GBT information.
- miner.php custom formatting and row counter '#'
- Drillbit: Fix for underestimating hash rate from Bitfury devices
- Send per-core hashrates at regular ~5min intervals back to cta devices.
- Calculate the cta per core hashrate at 5 minute intervals.
- Check the bits of the correct core in cta bit count.
- Display the bit count along with the bitmap for each cta core in the API stats
output.
- Store and display the per core hashrate on cta relative to each work restart.
- Decrease the time we wait for unsetting a core on the cta bitmap to correspond
with the lower max diff of 32.
- Set max diff on cointerra devices to 32 which is still only 11 shares per
second but allows for earlier confirmation of per core hashrates.
- Keep track of when the last restart and work updates were triggered and
provide helper functions for knowing the time since then.
- hashfast make api stats field names unique
- Fix gcc longjmp warning in api.c
- Add a per-core hashrate to the cta API stats.
- miner.php support edevs and estats
- API - put edevstatus where it was supposed to be
- Icarus - allow timing mode to work with ANU and not slow it down
- drillbit - remove warnings
- drillbit - minor code tidy up
- Drillbit: Change language around 'void' to warning about limiter disabled
- Drillbit: Fix accidental over-counting of HW errors
- Drillbit: --drillbit-auto parameter for tweakable custom tuning of ASIC speeds
- Drillbit: Output warning if board reports void warranty
- Drillbit: Add Avalon & drillbit-autotune notes to ASIC-README
- Drillbit: Limit work sent out to 8 units in a single pass, was DoSing a full
double scroll
- Drillbit: Move drillbit_empty_buffer calls to only when errors occur, were
limiting performance on Windows
- Fix Windows bug with libusb_reset_device returning SUCCESS for disconnected
device
- Drillbit: Fix some warnings
- Drillbit: Add --drillbit-autotune option for device to dynamically alter clock
speed
- Drillbit: Fix typo in previous commit
- Drillbit: Remove default config in cgminer, rely on defaults in firmware
- Drillbit: Combine split USB transfer for sending new work, reduce overhead
- Drillbit: Add support for protocol V4, with device-agnostic board
configuration data
- Drillbit driver: Add support for Avalon-based Drillbit miners
- API - add edevs and estats - to only show enabled devices
- Check device data exists on a hfa instance before trying to reinit it.
- Print off what quadrant regulator failed if known in hfa driver.
- Reset all the stats on autovoltage complete in cta driver.
- Use correct diff instead of diffbits in cta driver.
- Whitelist all firmwares <= 0.5 on hfa for software rolling of ntime.
- Avoid a memory leak by reusing the ntime field when rolling stratum work.
- Clear the pipe bitmap on cta only when no share has occurred for 2 hours
instead of 1.
- Cta share_hashes should be added, and we can base it on device wdiff instead
of pool work difficulty for more accurate hashrates.
- Since the device runtime is now reset, the Raw hashrate entry in the cta API
output is no longer meaningful.
- Look for autovoltage returning to zero on cta driver and reset stats at that
point since the hashrate is unreliable till then.
- ants1 - cgminerise applog calls
- Default to stratum+tcp:// on any urls that don't have a prefix instead of
http.
- Trivial cta style changes.
- ants1 - fix/enable temperature checking and remove unneeded temp_old
- ants1 - move local cgpu variables to info structure
- ants1 use a klist to store work and copied work
- Simplify dramatically the cross-process cgminer locking through use of flock
instead of sysv semaphores.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
KTC
Newbie
*
Offline Offline

Activity: 3

You are actually reading this message.


View Profile
March 18, 2014, 02:50:43 PM
 #14689

Hi, I build myself cgminer 4.2.0 on Kali Linux 32 bits (VMWare)

Code:
# ./configure --enable-icarus

The problem is that I don't have a beautiful CLI with menus, I just have log of accepted shares...
What I'm missing to have the CLI with the menu ?

This is what I call "menu":
Code:
[U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit

Example of what I've got:
Code:
[2014-03-18 10:40:39] Started cgminer 4.2.0                                      
 [2014-03-18 10:40:42] No devices detected!                    
 [2014-03-18 10:40:42] Waiting for USB hotplug devices or press q to quit                                    
 [2014-03-18 10:40:42] Probing for an alive pool                    
 [2014-03-18 10:40:42] Pool 0 difficulty changed to 16                    
 [2014-03-18 10:40:42] Pool 0 difficulty changed to 4                    
 [2014-03-18 10:40:43] Network diff set to 4.25G                    
 [2014-03-18 10:40:52] Hotplug: Icarus added ANU 0                    
 [2014-03-18 10:40:52] Hotplug: Icarus added ANU 1                    
 [2014-03-18 10:40:55] Accepted 3c3ef37d Diff 4/4 ANU 0                    
 [2014-03-18 10:40:59] Accepted 1ed887b3 Diff 8/4 ANU 0                    
^C [2014-03-18 10:41:09] Shutdown signal received.                    
 [2014-03-18 10:41:10]
Summary of runtime statistics:
                    
 [2014-03-18 10:41:10] Started at [2014-03-18 10:40:43]                    
 [2014-03-18 10:41:10] Pool: stratum+tcp://nl1.ghash.io:3333                    
 [2014-03-18 10:41:10] Runtime: 0 hrs : 0 mins : 27 secs                    
 [2014-03-18 10:41:10] Average hashrate: 2814.3 Megahash/s                    
 [2014-03-18 10:41:10] Solved blocks: 0                    
 [2014-03-18 10:41:10] Best share difficulty: 8                    
 [2014-03-18 10:41:10] Share submissions: 2                    
 [2014-03-18 10:41:10] Accepted shares: 2                    
 [2014-03-18 10:41:10] Rejected shares: 0                    
 [2014-03-18 10:41:10] Accepted difficulty shares: 8                    
 [2014-03-18 10:41:10] Rejected difficulty shares: 0                    
 [2014-03-18 10:41:10] Reject ratio: 0.0%                    
 [2014-03-18 10:41:10] Hardware errors: 0                    
 [2014-03-18 10:41:10] Utility (accepted shares / min): 5.20/min                    
 [2014-03-18 10:41:10] Work Utility (diff1 shares solved / min): 41.56/min
                    
 [2014-03-18 10:41:10] Stale submissions discarded due to new blocks: 0                    
 [2014-03-18 10:41:10] Unable to get work from server occasions: 0                    
 [2014-03-18 10:41:10] Work items generated locally: 41                    
 [2014-03-18 10:41:10] Submitting work remotely delay occasions: 0                    
 [2014-03-18 10:41:10] New blocks detected on network: 1
                    
 [2014-03-18 10:41:10] Summary of per device statistics:
                    
 [2014-03-18 10:41:10] ANU0 (5s):1.351G (avg):1.809Gh/s | A:8 R:0 HW:0 WU:36.1/m                    
 [2014-03-18 10:41:10] ANU1 (5s):1.328G (avg):1.748Gh/s | A:0 R:0 HW:0 WU:16.4/m                    
 [2014-03-18 10:41:10]

Hello world !
Buchi-88
Legendary
*
Offline Offline

Activity: 1092


My Solo Block: 401934


View Profile
March 18, 2014, 06:57:31 PM
 #14690

@ckolivas

THX for the fast Fix and i will test it with U1 HW 1.2 and with U2+ Wink

regards


                ,╓▄▄▄▄▄▄▄▄▄╓                 
            ╓▄█████████████████▄╖           
         ╓▄█████▀▀'▒,,,,,╠'▀▀█████▄,         
       ,▓███▀╜,▄▄███████████▄▄,╙▀████╖       
      ▄███▀ ▄█████▀▀"``╙"▀▀█████▄ ▀███▄     
     ▓███╜╓████▀ ,▄▄█████▄▄, ▀████,╙███▌     
    ▓███`╔███▀ ╓▓███▀▀▀▀▀████╖ ▀███@"███▌   
   ]███▌┌███▌ ▐███         ███▄ ▐███ ▐███,   
   ▐███ ▐███ .███           ███  ███▌ ███▌   
   ▐███ ▐███ '███           ███  ███▌ ███▌   
   ]███@╙███@ ▀██▌        ,▄██▌ ▐███ ▐███`   
    ▓███ ▐███▄ ╙██▀╩     9███╜ ╔███▀,███▌   
     ████,╙███▌               ▓███╜,████     
      ▀███▄ ▀╜                 ▀▀ ▄███▌     
       ╙████▄,                 ╓▄████╜       
         ╙█████▄▄╓,       ,╓▄▄█████▀         
            ▀▀█████████████████▀▀           
                '▀▀▀▀▀▀▀▀▀▀▀'

CloakCoin |  Trustless Anonymous Cryptocurrency |  PoSA3
Forum | Bitcointalk | Twitter | Slack |  Facebook |  VK |  Reddit |  CloakTV |  Instagram |  IRC-Chat |  Faucet
ndr76
Newbie
*
Offline Offline

Activity: 28


View Profile
March 18, 2014, 07:16:06 PM
 #14691

Thanks for the release.
However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 18, 2014, 08:04:55 PM
 #14692

Thanks for the release.
However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.
No you're reading it wrong. It will not mine solo unless you go to the effort of setting up bitcoind AND adding it as a pool and NOT follow the instructions that discretely say to add a btc address. It does NOT change default behaviour one bit for existing miners with existing configurations.

EDIT: Or is your concern existing solo miners? The previous versions of cgminer could not meaningfully mine solo so I didn't think anyone was trying to.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 292


View Profile WWW
March 18, 2014, 08:31:54 PM
 #14693

EDIT: Or is your concern existing solo miners? The previous versions of cgminer could not meaningfully mine solo so I didn't think anyone was trying to.
I did not know this. I have frequently solo-mined with my few Block Erupters in the past, and even with my GPUs in years past, thinking I was essentially playing the lottery. I'm a little disappointed to learn that I was basically doing nothing. (But only a little disappointed; I knew my chance of actually hitting anything was pretty darn close to zero.)

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
ndr76
Newbie
*
Offline Offline

Activity: 28


View Profile
March 18, 2014, 09:02:41 PM
 #14694

No you're reading it wrong. It will not mine solo unless you go to the effort of setting up bitcoind AND adding it as a pool and NOT follow the instructions that discretely say to add a btc address. It does NOT change default behaviour one bit for existing miners with existing configurations.

EDIT: Or is your concern existing solo miners? The previous versions of cgminer could not meaningfully mine solo so I didn't think anyone was trying to.

My concern was existing solo miners.
I have always had bitcoind running and I was mining with these options:
cgminer -o http://127.0.0.1:8332 -u bitcoinrpc -p $PASSWORD

cgminer was displaying this:
Connected to 127.0.0.1 diff 4.25G without LP as user bitcoinrpc

Given that the difficulty matched the network difficulty I always assumed it was solo mining, was it not? How was I not mining "in a meaningful way" ? =)
Also I always assumed that cgminer would ask bitcoind for an address for the mined btc, in a similar way in which it asks for the difficulty.
The fact that it could have been sending the mined btc to some hard-coded address belonging to you really didn't cross my mind, and I still think it's a bit strange as a default. =/
So that's why when I read the 4.2.0 release notes I thought that this was a change in behaviour.
Were versions of cgminer previous to 4.2.0 already using your hard-coded address if one didn't specify --btc-address ?

Wouldn't it be possible to have the receiving address always displayed by cgminer while running? That would avoid any confusion, and would be quite an important piece of information to have. =)
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 18, 2014, 09:23:08 PM
 #14695

My concern was existing solo miners.
I have always had bitcoind running and I was mining with these options:
cgminer -o http://127.0.0.1:8332 -u bitcoinrpc -p $PASSWORD

cgminer was displaying this:
Connected to 127.0.0.1 diff 4.25G without LP as user bitcoinrpc

Given that the difficulty matched the network difficulty I always assumed it was solo mining, was it not? How was I not mining "in a meaningful way" ? =)
Bitcoind would run out of work usually around 5GH. Lower hashrates would indeed mine solo but it was very cpu intensive and inefficient.
Quote
Also I always assumed that cgminer would ask bitcoind for an address for the mined btc, in a similar way in which it asks for the difficulty.
The fact that it could have been sending the mined btc to some hard-coded address belonging to you really didn't cross my mind, and I still think it's a bit strange as a default. =/
So that's why when I read the 4.2.0 release notes I thought that this was a change in behaviour.
Were versions of cgminer previous to 4.2.0 already using your hard-coded address if one didn't specify --btc-address ?

Wouldn't it be possible to have the receiving address always displayed by cgminer while running?
That would avoid any confusion, and would be quite an important piece of information to have. =)
Sure, next version.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Askit2
Hero Member
*****
Offline Offline

Activity: 524


View Profile
March 18, 2014, 09:34:40 PM
 #14696

Thanks for the release.
However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.

Unless I misunderstood GBT that is the exact way it works. You don't mine to its address. You mine to an address you specify at least from a bitcoind. Pools that use it have a different GBT implementation so that you can't get all the pools money. Don't get me wrong I do wish it defaulted to the bitcoind's local address not some other address. I'm not saying its a cgminer thing.

Still I my bitcoind doesn't keep up with my setup as is so I really do like the upgrade. I do suppose I could have the GBT thing wrong but I seem to remember it that way. Part of why I wish bitcoind had stratum instead.

I appreciate donations at ( 1NwkQdmomQPLtdes5KuZhB1D22p7ZGRy4p )
If I am helping in the CGMiner thread give it to Con or Kano. They do the work there.
If you want to sign up for a coinbase account I would appreciate it if you use my referral link. US people now wire, 1% fee give or take a little for sending to your bank account. https://coinbase.com/?r=515bf6145682db9d11000028&utm_campaign=user-referral&src=
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 18, 2014, 10:01:13 PM
 #14697

Yes you have to specify a bitcoin address when mining GBT solo. When you were mining with getwork to bitcoind, bitcoind would randomly give you new addresses but no such option exists with GBT solo since you are building everything from scratch. Mind you, when you are mining to a pool with stratum, that pool is actually talking GBT solo to its own bitcoind anyway. The issue is that stratum itself, or a more comprehensive mining communication protocol could be built into bitcoind directly, but the bitcoind devs feel that as much mining code should be separated from bitcoind as possible, to not associate bitcoind with the concept of mining. Seems silly if you ask me but meh, I got tired of arguing that one, it's not like bitcoin exists without mining so there's no point pretending it has nothing to do with it.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Askit2
Hero Member
*****
Offline Offline

Activity: 524


View Profile
March 18, 2014, 10:21:13 PM
 #14698

Ok so on starting with -o -p -u and --btc-address I saved a conf file and didn't see a difference between that and my previous one.  All options had correct values but I didn't see an additional pool appended to my list. I didn't avoid loading my previous conf file.

Is the bitcoin address not saved into the config file? I assume it is and that my previous config loading messed things up.

Is it ok if I omit the -o -p and -u with the appropriate info in them and just keep --btc-address in my command line will it still mine paying to my address?

I appreciate donations at ( 1NwkQdmomQPLtdes5KuZhB1D22p7ZGRy4p )
If I am helping in the CGMiner thread give it to Con or Kano. They do the work there.
If you want to sign up for a coinbase account I would appreciate it if you use my referral link. US people now wire, 1% fee give or take a little for sending to your bank account. https://coinbase.com/?r=515bf6145682db9d11000028&utm_campaign=user-referral&src=
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
March 18, 2014, 10:23:15 PM
 #14699

Ok so on starting with -o -p -u and --btc-address I saved a conf file and didn't see a difference between that and my previous one.  All options had correct values but I didn't see an additional pool appended to my list. I didn't avoid loading my previous conf file.

Is the bitcoin address not saved into the config file? I assume it is and that my previous config loading messed things up.

Is it ok if I omit the -o -p and -u with the appropriate info in them and just keep --btc-address in my command line will it still mine paying to my address?
No, the write config from menu is really limited in what it stores at the moment, storing only about 1/3 of the options cos I never got around to updating it. You'll have to manually edit the file to add it or keep the address on your command line.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
felixonmars
Newbie
*
Offline Offline

Activity: 5


View Profile
March 19, 2014, 08:47:13 AM
 #14700

Hi I'm getting the following error when trying to compile the v4.2.0 tag on github:

Code:
  CC       cgminer-driver-minion.o
In file included from miner.h:26:0,
                 from driver-avalon2.c:36:
driver-avalon2.c: In function 'avalon2_stratum_pkgs':
driver-avalon2.c:397:20: error: 'struct stratum_work' has no member named 'cb_len'
         pool->swork.cb_len,
                    ^
logging.h:40:42: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                          ^
driver-avalon2.c:400:13: error: 'struct pool' has no member named 'merkle_offset'
         pool->merkle_offset,
             ^
logging.h:40:42: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                          ^
driver-avalon2.c:401:20: error: 'struct stratum_work' has no member named 'merkles'
         pool->swork.merkles);
                    ^
logging.h:40:42: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                          ^
In file included from /usr/include/pthread.h:22:0,
                 from driver-avalon2.c:16:
driver-avalon2.c:403:27: error: 'struct stratum_work' has no member named 'cb_len'
  tmp = be32toh(pool->swork.cb_len);
                           ^
driver-avalon2.c:412:20: error: 'struct pool' has no member named 'merkle_offset'
  tmp = be32toh(pool->merkle_offset);
                    ^
driver-avalon2.c:415:27: error: 'struct stratum_work' has no member named 'merkles'
  tmp = be32toh(pool->swork.merkles);
                           ^
driver-avalon2.c:454:17: error: 'struct stratum_work' has no member named 'cb_len'
  a = pool->swork.cb_len / AVA2_P_DATA_LEN;
                 ^
driver-avalon2.c:455:17: error: 'struct stratum_work' has no member named 'cb_len'
  b = pool->swork.cb_len % AVA2_P_DATA_LEN;
                 ^
driver-avalon2.c:471:17: error: 'struct stratum_work' has no member named 'merkles'
  b = pool->swork.merkles;
                 ^
driver-avalon2.c: In function 'avalon2_scanhash':
driver-avalon2.c:695:18: error: 'struct stratum_work' has no member named 'cb_len'
   if (pool->swork.cb_len > AVA2_P_COINBASE_SIZE)
                  ^
driver-avalon2.c:697:18: error: 'struct stratum_work' has no member named 'merkles'
   if (pool->swork.merkles > AVA2_P_MERKLES_COUNT)
                  ^
driver-avalon2.c: In function 'avalon2_api_stats':
driver-avalon2.c:760:3: warning: passing argument 3 of 'api_add_string' from incompatible pointer type [enabled by default]
   root = api_add_string(root, buf, &(info->mm_version[i]), false);
   ^
In file included from driver-avalon2.c:36:0:
miner.h:1487:25: note: expected 'char *' but argument is of type 'char (*)[16]'
 extern struct api_data *api_add_string(struct api_data *root, char *name, char *data, bool copy_data);
                         ^
driver-avalon2.c: At top level:
driver-avalon2.c:815:2: warning: initialization from incompatible pointer type [enabled by default]
  .drv_detect = avalon2_detect,
  ^
driver-avalon2.c:815:2: warning: (near initialization for 'avalon2_drv.drv_detect') [enabled by default]
Makefile:1137: recipe for target 'cgminer-driver-avalon2.o' failed
make[2]: *** [cgminer-driver-avalon2.o] Error 1
make[2]: *** Waiting for unfinished jobs....
driver-minion.c: In function 'minion_spi_reply':
driver-minion.c:1934:8: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
    read(minioninfo->gpiointfd, &c, 1);
        ^
make[2]: Leaving directory '/build/cgminer/src/cgminer'
Makefile:1243: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/build/cgminer/src/cgminer'
Makefile:648: recipe for target 'all' failed
make: *** [all] Error 2

Please help, thanks!
Pages: « 1 ... 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 [735] 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 ... 830 »
  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!