It appears to be an issue with nicehash control -- I have this issue with any CCminer 1.1, 1.2, and the latest NVMiner build.

Behavior only present on auto-switching.

The behavior is present across multiple rigs (780 rigs, 750ti rigs). Running the miner with a built in pause command does not change the behavior either.

Again, it still generates shares, but they are either not submitted to my deposit address, or it is running in benchmark mode.

For some reason when I use this, if I switch from any algo, to another, and back to original algo (doesn't matter which), the original algorithm will not mine. It winds up in benchmark mode for some reason (generates shares, but none are submitted). This is fixed if it closes the window and restarts (maxtime reached).

Anyone else experience this issue? Don't like missing 30 minutes of hashing everytime I switch an algo

I didn't look into PoS too heavily. Considering most of the code appears to be a direct yacoin fork with the bare minimal alterations to function, and their PoS still works, I'd expect it to be alright. The real problem, is the orphan problem. Without a DNSseed, longer block/retarget time, etc, this will remain a large problem. Its something that could easily be fixed via a hard-fork, but the only real way to get that to happen is for cryptsy to agree to fork their wallet as well. (Make the money fork, and the miners follow). If it were hardforked, could also include coincontrol, and look at PoS pretty easily at that time as well, but as I say, both those features are luxuries compared to the orphan issue.

When trying to rebuild the database -- it will be stuck on the splash screen for a long time, and be "unresponsive" (I.E. if you click the icon, or splash icon, windows will tell you the program is not responding, linux will do nothing -- this is why I recommend running with logtimestamps, so you can see it is still adding the blocks from disk. Its painful either way, but atleast rebuilding isn't too bad.

Technically you should be able to interrupt the process and resume it (as it will likely take 100% usage from a core, and significant disk usage), but as there is no way to "cleanly" exit, you do run the risk of corrupting the new database. FWIW, when I reindexed on my WinXP laptop for testing, it kept going to hibernate, and would wake up and resume indexing w/o issue.

Both prebuilt binaries I've posted (Windows/Ubuntu) contain the respective most recent version of openSSL, which fixes heartbleed. If you built it yourself, it will use whatever you have installed.

I'd mined this coin back during launch, sad to see it has been so forgotten.

Since the dev seems to have totally abandoned this project (and doesn't reply to PM's), I've gone ahead and updated the source a bit. It now starts MUCH faster. As a result of this however, the way the database is handled has changed, and it will require the database to be rebuilt (see below).

Code, with Linux & Windows pre-built binaries included is at https://github.com/maelstrom987/CopperBars

For Windows users - head to the release folder, and download CopperBars.exe. This was built using msys and minGW. The .pro file used to build this is included, and can be rebuilt yourself if desired.

For Linux users CopperBars QT is already built in the main folder, built on Debian 13.10 for me. You'll probably want to rebuilt it yourself.

As far as what's changed - There were many minor changes, but the big ones were as follows:
Updated net.cpp code to allow for more total connections, and to accept to the -maxoutbound command
Updated main.cpp, checkpoints.cpp to allow for a faster startup (basically used a newer yacoin fork)
Updated checkpoints.cpp (but only testnet) to include a handful of checkpoints for what appears to be the longest chain. These are not currently used, but may be helpful if someone wants to verify their chain. If there was actual interest from people still mining this coin, I'd make them included in the launch version.

Finally, a note about rebuilding the database - When you launch this new version, it will tell you that there was an error loading blkindex.dat. This is completely normal, and it has not corrupted your blockchain.
At this point, you have two options:
1) Redownload the entire blockchain (see you in 2 weeks)
2) Backup blkindex.dat, blk0001.dat somewhere safe.  Make sure they are out of the config folder. Delete everything except wallet.dat and CopperBars.conf (or similar named) from the config folder. Preferably, add logtimestamps=1 to your conf file, or launch with -logtimestamps. Then, add loadblock=C:\blk0001.dat to your conf file, or launch with -loadblock=C:\blk0001.dat (assuming you have placed a copy of your original blk0001.dat at C:\, change the path to wherever you've placed a copy of this file. It must NOT be in the config folder)

Method number 2 will take anywhere from 3-40 hours to complete. My 4770k with Raid 0 SSDs clocked in at about 3 hours running Win7 64. My old clunker with a Q6600 and 2GB of ram running debian off a thumbdrive took close to 40 hours, while other PCs/mining rigs I've got took somewhere in between. This is why I highly recommend launching with logtimestamps, so you can see that it is still working by loading the log file. It will also tell you what block you're on. At the time of this writing (10:00AM CST), I currently have 1474746 blocks. After this first launch, remove the -loadblock line. After this, the client will launch within a minute, at most for most machine.

I also have a private pool running, which I may make public if there is any interest -- it does appear to suffer from the same orphan problems that were there when this coin launched, though part of if is that there are so few nodes that have listen=1 enabled and are actually connectable, so it is difficult to propagate a block quickly.


Hope this helps others who are still giving this coin a look from time to time. Feel free to PM/Post with questions.

WTS 1368 METH. Confirm on my last block in ~80 blocks. PM with offers