How is this different from ZenCash? (which is a well established coin that uses equihash and has paying masternodes, which they call secure nodes, but they're the same thing) 
Is there anywhere that has info on the dev team?  Can't find any info on their website. 
It's also concerning that there are only 65 commits on the github page and only 2 contributors, 1 of which is the snowgem account, so there's no link to other projects that dev has worked on.

Not saying this isn't a good project, but those are red flags in my experience. 

Hey thanks for the fantastic firmware upgrades, they really make a big difference in keeping these profitable until there's something to mine with them lol. 

I noticed something in my farm.  I have 9 D3's, all on 1.12 version.  And when I change the settings across the board to identical freq. and voltage, almost invariably, the 3rd hash board will get immediately more hardware faults than the other two boards.  By a ton.  (hundreds if not thousands in a few minutes)  I'm just wondering if there may be something in the code that is treating board 3 differently than the other two voltage wise, because it seems to possibly be a deficiency in the voltage causing the escalated hardware fault levels, since as i raise them the problem goes away.  This is obviously to be expected, but the disparity between the boards being so consistent is unusual.

Anyway, thanks for the work, looking forward to a stable release of v. 2.0!

T.J.

Reposting my comment from their reddit thread here.. it makes me chuckle:

I just attempted to load a bitcoin2x node compiled from their github codebase (knowing that it hasn't officially forked yet, but getting a head start), and though the node hasn't fully synced yet (300,000/500,000 blocks) I attempted to create a segwit address on the 'segwit2x' chain, which is essentially bitcoin core 0.15.1 with a new algorithm, expecting it to work without a problem.

Unfortunately, I get this error:
$ bitcoin2x-cli addwitnessaddress 1Ap4Qq6tnAdMEcL2LSNQFxxxxxxxxxx
error code: -4
error message: Segregated witness not enabled on network


If the 'segwit2x' guys haven't bothered to actually update their github to enable segwit, the day of the hard fork, that's moderately hilarious.

At least it gives people somewhere to point their X11 miners at since there are an literal plethora of them out there that need a distraction from the miserable returns they've been getting lately.

I've had to ship two orders in the past few months to Bitmain for repair, 1 L3+ hashboard and 2 D3 hashboards.  In my experience, they're very fast on returning them.  My only delay on the first repair was because they closed for a week for holiday.  My advice, use USPS, and ship the boards using the 3-4 day option Priority International Express or whatever its called.  For a normal size box for hashboards it cost me $60 or so.  It arrives, then it will take them a week to log it into their system so don't freak out when it doesn't get marked received right away.  Once they do mark it received, they'll have it shipped out within 3 days and they usually ship it UPS red so it gets back to you in 1-2 days. Door to door it takes about 3 weeks.. not terrible as far as warranty repair return times go.  The fact that they ship it back to you express is fantastic since it shaves at least a week off your downtime.

The trick is to ship it directly to Hong Kong, do NOT ship to California or they'll put the board on the slow boat and you wont' see a return shipment for weeks.  Shipping might cost you more up front, but you'll make up for that in the mining time you won't lose waiting on California to get the board returned and mail it back to you.  They don't actually do any L3 or D3 repairs on site there, so sending it to them is just adding a middleman.

I had the same problem the past several hours (5am - 9am or so), where mining periodically went to 0, switched to my secondary pool, then came back to zpool.  No connection problems on my end, the miners never turned off, it just disconnected from Zpool without explanation.  (The gap from 6-10pm was scheduled maintenance)

Ask Hellcatz in Luckpool's chat

Can you point me to a source describing what changes will need to be made on my securenode in order to switch from the alpha to the beta, if any?

This is a great start guys, love the look of the platform.  As soon as there is a more robust strategy coding function like pine script or something similar I'll be the first in line!

https://github.com/Kronecoin/Kronecoin/commits/master

The commits are very minimal for a project under development, there's only 1 contributor.  There are no people following the project, etc. etc.

The claim is that they want to allow people of limited means to mine without expensive hardware, but the algo is scrypt which is an ASIC algo, so as soon as anyone with an L3+ points it at this coin the difficulty will rocket undermining the stated purpose. 

I'll pass for now, but keep at it.

Has anybody had an issue where an entire board just disappears from the miner status page?  Not just a few chips marked inactive or bad, the whole board 2 line is missing.  If so, were you able to resolve it without a warranty claim?

I have tried everything I can think of to get it working again but nothing has done any good.

I've got it running on a 2400w server PSU, so power isn't an issue.  All the PCIe cables have been tested on other hashing boards so I know the power cables are good that the missing board is using, and i've switched out the control board connectors as well thinking one wire might have been knicked or something causing it not to detect.  No change.  Also tried flashing the control board software by SD Card back to the Jan 2017 firmware, still no change.  All connections seem solid, and the board doesn't have any evident damage to it such as blown caps or bad soldering.

I'm out of ideas that could have caused it, but it's really weird given that it's only been online for a week and it was working at 504Mh/s until it just stopped working yesterday or today.

I  REALLY don't want to have to send the entire miner back to bitmain, even to bitmain here in the US, because it will be a huge profit loss for all 4 boards to go offline for 4-6 weeks.

Ahh... I was wondering how to set individual difficulty .. I'll give that a shot to see if I can squeeze some better perf. out of it.  Thanks for the tip.

I've just gone back to using krnlx in the script since the performance is nearly identical as far as i can tell and it's stable without having to worry whether watchdog will kill it or not.

I ran the 2.2 version of TPruvot ccminer w/ skunk and got horrible hashrates.  I will recompile and test it again, but for now, krnlx is the fastest for me.  I'm not sure why there is a perceived drop of 30% in his setup, but I'm not seeing that at all.  I'm mining exactly at the expected coin rate per day based on both whattomine.com and crypto-economy.com calculators (450mh/s nets me around 550 coins a day +/- 25).  I will note that when I tried changing clock settings a little higher it really affected hashrates, dropping them over time considerably.  There is definitely a 'sweet spot' clock rate for skunk, and deviation appears to create greatly reduced production.  Also mining at -i 26 seems to have reduced my hashrates, so -i 25 is the proper setting for 1070 / 1080 Ti at least.  Lower settings or leaving -i blank greatly reduce hashrates, as is to be expected.

I'll update with the results of a recompile with tpruvot's most recent ccminer release on 0018.

Thanks for keeping an eye on this.

EDIT: the latest tpruvot ccminer release runs at just about the same hashrate as krnlx within 1-2mh/s (463mh/s vs. 462mh/s) and in a 2 hour test it mined 26-27 coins an hour on sigt.pool.mn which is a small number more than I was mining before, but it's a shjort test length so I'll update again after 24 hours to get a better average.  I was able to run tpruvot with skunk from command line in guake, but it crashes for some reason when running from the script almost immediately after it starts mining (before watchdog kicks in).  Not sure why that's happening, the command line is the same in both as I have it configured.

In the end, I don't see a dramatic difference between the two miners' performance except that I know krnlx runs from the script properly, whereas TPccminer 2.2 does not work in the script yet.  I'll keep playing around with it to see if some code in the script I added has an error. It's strange because the miner actually starts mining properly, but then errors out, rather than just not running at all which is normally how that goes.

Where are you getting your expected shares tally from?  I think that varies based on difficulty of the shares calculated which is determined by the stratum server, not your machine, so i don't know how you'd reliably determine expected shares in order to reason that you're losing 30%.  Right now with 460-480Mh/s I'm getting about 22 coins an hour, which seems to be in line with the predictions of whattomine.com's mining calculator profit wise, ~ 525-550 coins a day @ $.07 per coin = ~$37-38.00 /day.

 I haven't mined at length with TPruvot ccminer 2.2 with the current configuration on my system, so I don't know if it would result in higher profit, but krnlx seems to be on point for profitability estimates now that I've got it properly configured and my clock settings are dialed in.   FWIW, I'm not sure why you're downclocking your memory so much.  I overclock mine +100 on 1070s and +800 on 1080 Tis.  I see no benefit from underclocking memory on Nvidia cards really since power usage comes from core clock speed primarily, and it could result in unstable mining to underclock memory too much.

EDIT:  I had the under use problem with Watchdog as well, but I took care of that by raising my clock speed on my GPUs from +100 to +125 and setting intensity to -i 25, now I don't have watchdog restarts at all. 

It zeroes out that partition because there were some problems with the script being run on the windows partition on boot that were fixed by moving the script to the / partition on the first bootup of the system in version 0018.  I would think that once you've got your thumb drive all configured, you could just dd the / partition (and any other linux partitions) to a hard drive alongside windows so long as you know how to edit the grub configuration or windows config manager (BCD) to boot to the correct linux partition for the o/s in order to get dual boot to work.  That can be tricky though, so i wouldn't recommend doing it on a drive you're afraid to lose data on without backing up everything first.

How do you lose 30% of expected shares?  You mean rejected shares? 

Thanks for posting this info - I banged my head against a wall for quite a while trying to figure this error out before giving up on it.  This worked like a charm for me.

Though I think I'm still getting really low hashrates for skunk - whattomine thinks I should be getting 450mh/s with 5 1080 Tis and 7 1070s but I was only getting around 300mh/s.  With the new krnlx miner I'm still only getting about 370Mh/s, which still seems pretty low.  My miner also restarts with the watchdog reporting under utilization.  My 1080 Tis are only running at about 60% and 1070s at 80-85% capacity.  Can't figure out what's causing that.

EDIT: I added the '-i 25' flag to the command line and boosted core clock on the 1070s to +125 now I'm up at 480mh/s =)

That's not a bug, its a feature.  It means your settings for power will be configured each time the script loads.  Persistence mode would be if you didn't use the script and set the configuration in xserver settings panel manually, then saved the profile. That would load persistent settings every time you boot (pointless unless you disable power settings in the script, which you probably don't want to do)

Well, I fixed it.. although I'm not entirely sure what did it.  I added a dummy plug to that card, and moved the slot configuration around, then went down to 6 gpus which allowed it to boot again, then rebooted and plugged the other 6 in now all 12 have xserver terminals attached to them so the temp monitoring will work.  No clue what caused, or fixed the problem.  Such is the way of tech I guess... lol.

That's what I thought too... I put a headless plug on it and it recognized that there was a screen there, but when I restarted after saving that config it won't boot now.  Teamviewer never comes online, and the screen never shows any indication of loading the o/s.

I'm going to do a clean install and see if I can fix it that way since I upgraded to CUDA 9.0, and that might have caused some problems.

the card that's giving the issue is an EVGA 1080 Ti SC Black Edition, but I have 3 of those and the other 2 are fine.  It's recognizing the card, so I don't think the riser is the issue, but I guess anything is possible.  I'll dig into it some more and see what I can figure out.

Thanks for the assist.

Hey FZ,

I ran into an issue that I can't figure out how to fix.  I've got 12 gpus on a TB250-BTC Pro, and all of them work fine, except the last one GPU12 (PCI:12:0:0) which doesn't seem to start an xserver instance on boot.  Because it doesn't load xserver, the fan and power settings are unavailable for editing, so the card runs too hot and causes power throttling, and occasionally a reboot.

Any idea how to fix that?  I checked the /etc/X11/xorg.conf file and it looks fine from what I can tell (all display device settings are there and look the same).

Thanks for your help.