Bitcoin Forum
November 09, 2024, 12:35:19 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 680 681 682 683 684 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 ... 843 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5805619 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. (3 posts by 1+ user deleted.)
wolfey2014
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile WWW
March 14, 2014, 01:17:02 AM
Last edit: March 14, 2014, 05:14:17 AM by wolfey2014
 #14581

Hello everyone!
This data will definitely help with tweaking your GridSeed 5 chip USB miner/s.

I just received this data from GRIDSEED via HASHRA.com today. 3-13-14
I'm paraphrasing for general clarity.
I've also added some of my own observations based on direct experience with my own GS5's.

GRIDSEED GS3355 5 Chip USB Miner - Flashing RED and GREEN LED's - What They Actually Mean.

All timings are either approximate or exact, if not darn close!
Your clock speed may vary slightly. Wink

GREEN flashing LED means - 5V is ON / drive electronics are powered up.
GREEN LED is ON for 1 second, OFF for 1 second.

RED flashing LED - ON 3 seconds / OFF 3 seconds means - Miner Is Hashing /

Processing Data.

RED flashing LED - ON 60 to 70 seconds - OFF 60 to 70 seconds:
Miner is Not Hashing / Processing Data.

If Fan is OFF and RED LED IS STUCK ON or OFF i.e. not flashing:
12V is OFF - 5V is ON.

FAN is ON but no GREEN OR RED LED's are flashing ON or OFF, means:
12V ON - 5V OFF.

When first powering the miner on, the best sequence I have found is:
First, 12V ON
Second, 5V (USB POWER) ON

After 5V power is turned ON, after a few seconds, the GREEN LED's will start
to flash ON/OFF as written above.
After 12V power is turned ON, in about 60 to 70 seconds,
the RED LED's will start to sequence ON/OFF as written above.

Hope this helps! Smiley
Peace
Wolfey2014

LR6U7jB2Fb4pJYogbergqQHZgBRQ5UAqBG (LTC)
1G9uTT2YvygQXPMw4CaLWPJmg6asJBqM5f (BTC)
DMtMWd492Y4PrzZBA6fvkXywnGtgNcFdBd (DOGE)

I Modify Miners Professionally! PM me for details!
jmordica
Member
**
Offline Offline

Activity: 99
Merit: 10


View Profile
March 14, 2014, 03:07:10 PM
 #14582

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

{
    "pools": [
        {
            "url": "stratum+tcp://ltc.ghash.io:3333",
            "user": "worker.something",
            "pass": "x"
        },
        {
            "url": "stratum+tcp://ny.clevermining.com:3333",
            "user": "worker.something",
            "pass": "x"
        }
    ],
    "gridseed-options": {
        "baud": "115200",
        "freq": "850",
        "chips": "5",
        "modules": "1",
        "usefifo": "0"
    },
    "api-listen": true,
    "api-mcast-port": "4028",
    "api-port": "4028",
    "expiry": "120",
    "hotplug": "5",
    "log": "5",
    "no-pool-disable": true,
    "queue": "1",
    "scan-time": "30",
    "scrypt": true,
    "shares": "0",
    "kernel-path": "/usr/local/bin",
    "api-allow": "W:127.0.0.1"
}
JoseSan
Member
**
Offline Offline

Activity: 117
Merit: 10


View Profile
March 14, 2014, 03:54:01 PM
 #14583

   "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).
jmordica
Member
**
Offline Offline

Activity: 99
Merit: 10


View Profile
March 14, 2014, 04:48:47 PM
 #14584

   "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.
JoseSan
Member
**
Offline Offline

Activity: 117
Merit: 10


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

   "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.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
-ck (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


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

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?

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
os2sam
Legendary
*
Offline Offline

Activity: 3586
Merit: 1098


Think for yourself


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

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: 3976
Merit: 2640



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

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

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
BTCJoe
Newbie
*
Offline Offline

Activity: 38
Merit: 0


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

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 (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
-ck (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
March 18, 2014, 12:18:32 PM
Last edit: March 18, 2014, 12:34:46 PM by ckolivas
 #14592

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Buchi-88
Legendary
*
Offline Offline

Activity: 3976
Merit: 2640



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

@ckolivas

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

regards

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
ndr76
Newbie
*
Offline Offline

Activity: 28
Merit: 0


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

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 (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 295
Merit: 250


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

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
Merit: 0


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

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 (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Askit2
Hero Member
*****
Offline Offline

Activity: 981
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


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

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.

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
-ck (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 ... 680 681 682 683 684 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 ... 843 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!