Just got this up and running last night, and so far it looks like it's running like it should:

https://gitlab.com/salfter/zpool-switch

It'll work anywhere you can run Python.  It's developed and tested on Linux, so it'll be easiest to get it running there, but Mac OS X should be nearly as simple (so long as miner binaries are available).  It's untested under Windows, but as long as Python abstracts away things like starting and stopping processes well enough, it ought to work with no more than minimal modification.  

No devfee.  If you like it, you can always throw something in the tipjar (see below).

The stock configuration handles most of the algorithms zpool supports.  I left out sha256d and scrypt because it's pointless to GPU-mine them anymore, and there are maybe one or two others where I either couldn't get a GPU miner running under Linux or zpool appeared to have problems on its end.  The miners I picked ran fastest for me on my 1070s; if you're running AMD GPUs, you'll want to substitute different miners (and benchmark them to see which ones run fastest for a given algorithm).

Power management for nVIDIA GPUs is included.  I do have an AMD GPU (an RX460) in my desktop machine...might need to experiment with that a bit.

Speaking of getting miners running on Linux, I've put up Gentoo ebuilds for the ones that I'm using (and a few more besides):

https://gitlab.com/salfter/portage

A long-form Reuters piece on the MtGox shitshow:

https://www.reuters.com/investigates/special-report/bitcoin-gox/

(Edited to include the link I forgot to post originally...derp!)

I have a set of scripts that will generate ebuilds for pretty much any coin with a GitHub repo.  It's in my Portage overlay:

https://github.com/salfter/portage (look under net-p2p)

This overlay already has ebuilds for a bunch of different coins, most of which were generated by these scripts:

42 (as "coin42")
acoin
anoncoin
bitgem
digibyte
dogecoin
earthcoin
einsteinium
emark
fastcoin
fireflycoin
fluttercoin
fudcoin
grandcoin
joulecoin
nautiluscoin
netcoin
novacoin
opensourcecoin
ppcoin
primecoin
sexcoin
spots2
tekcoin
terracoin
titcoin
unobtanium
viacoin
yacoin
zetacoin

If your favorite coin isn't in there, you can probably get it up and syncing to the blockchain in a few minutes.  See https://salfter.github.io/ to get started.

https://gitlab.com/salfter/MinerSwitcher

MinerSwitcher is a profitability-based mining farm pool switcher. For the set of coins you have configured, it will determine how many of each you can produce given your hardware, and determine what they're worth in Bitcoin. It will then reconfigure all of your miners accordingly. MinerSwitcher is algorithm-agnostic: you can have a mix of sha256 miners, scrypt miners, etc., and each will be switched to whatever is most profitable for it to mine.

Sometimes pools go down without much notice. Before switching coins, MinerSwitcher verifies that at least one of your configured pools is still up. If it isn't, it prints a warning and moves on to the next most profitable pool.  (I suspect that adding a notification mechanism (Pushover, perhaps?) is in order.)  

If configured, MinerSwitcher will also send Pushover notifications when a miner is down or pools aren't reachable.

MiningSwitcher is built around my ProfitLib library.

Example output, right after startup:

Code:

Sun Oct 19 14:19:29 2014: running ProfitLib
BTC 0.00835068
UNO 0.00507514
ZET 0.00195981
Sun Oct 19 14:19:46 2014: checking BTC pools
Sun Oct 19 14:19:48 2014: switching miner4 to BTC Guild
Sun Oct 19 14:19:50 2014: switching miner4 to Eligius
Sun Oct 19 14:19:51 2014: switching miner3 to BTC Guild
Sun Oct 19 14:19:53 2014: switching miner3 to Eligius
Sun Oct 19 14:19:54 2014: switching miner2 to BTC Guild
Sun Oct 19 14:19:55 2014: switching miner2 to Eligius
42 0.00310407
LTC 0.00227397
ANC 0.00224579
FTC 0.00213765
BTG 0.00003768
Sun Oct 19 14:19:56 2014: checking 42 pools
Sun Oct 19 14:19:56 2014: switching miner1 to HashFaster 42
Sun Oct 19 14:19:59 2014: sleep for 30 minutes

miner1 is a bunch of Gridseeds (11 orbs and a blade) hanging off a Raspberry Pi, running bfgminer.  miner2 is a Bitfury rig with a couple of BFL Jalapeños, running cgminer.  miner3 and miner4 are Antminer S1s.  They're all on my home LAN, but MinerSwitcher should also work with remote mining rigs as long as the cgminer/bfgminer RPC port is accessible to the machine running MinerSwitcher.

The only outside data dependency is Cryptsy, for exchange-rate information.  All of the remaining information MinerSwitcher needs is obtained directly from coin daemons running locally. I currently have 10 daemons (DOGE & NMC can be merge-mined and are counted as appropriate) running on a box with 4 GB of RAM; it works, but RAM is overcommitted.  I'll be kicking it up to 10 GB in the next day or two.

Yes, there are sites such as CoinChoose and CoinWarz that aim to show you which coin is the most profitable for your hardware.  Hidden algorithms and bad data (usually from coin daemons that have gotten wedged) can throw their results off.  They also might not offer all the coins you'd like to mine.

ProfitLib is a Python library that works with the coin daemons you operate to find the most profitable coin.  Its only external data dependency is for market data from Cryptsy so you can compare all coins in terms of what they're worth in Bitcoin.  

https://gitlab.com/salfter/ProfitLib

I already have a shell script using it to control my miners by running the scripts I had already set up for CryptoSwitcher through an SSH connection...kinda janky, but it works. I have another project in the works that will use ProfitLib to control your entire mining farm from one place: all your sha256 miners on the most profitable sha256 coin, all your scrypt miners on the most profitable scrypt coin, etc.  I'll post more when it's ready.

Summer has well and truly arrived in Las Vegas.  I had moved all my mining hardware out into the garage a while back to get the heat and noise out of the house.  Most of my gear is working OK in triple-digit temperatures...fans speed up a bit, but they keep on moving.

The exception, though, is my Bitfury rig (nine H-boards with the appropriate backplane...the one that looks like a bunch of PCIe 1x slots).  In the cooler months, I was getting about 270 GH/s from it easily.  Every once in a while, it'd lose communication with some of the chips; restarting bfgminer would get it back on track.  As the weather got warmer, though, it started getting stuck more and more often.  I backed off the speed a bit.  It worked a while longer, then started getting wedged again.  I found that cgminer had added support for these systems (--enable-bab) and would adjust clock speeds automatically to optimize performance, so I built it and switched over from bfgminer.  It'll keep running now, but as the temperature outside pushed past 110 last week, hashrate fell down to about 120 GH/s!

I have heatsinks on the backside of the boards opposite each mining ASIC and voltage regulator.  I have it in a Spotswood frame with three fans good for over 270 cfm between them.  The other miners (two BFL Jalapeños, two Antminer S1s, a Gridseed blade miner, and a handful of Gridseed orb miners) are stock, except for some of the Gridseed orbs which I stacked together with standoffs so they'd take less space.  These other miners haven't skipped a beat.

Since the Raspberry Pi in the Bitfury rig was also controlling the BFL and Gridseed miners, I needed to set up another to take over for them when I moved the Bitfury into the laundry room.  Mining speed picked up to 200 GH/s...still not back to 270.  One of the fans had worn out, so I replaced it. (The fan was working before I moved the rig, but it had gotten noisy. Finding high-speed fans that aren't riced out with LEDs is harder than it should be, but that's fodder for another rant.) With the new fan in place and the rig still in the laundry room, it's finally back to mining at 270 GH/s.

CoinChoose's data has apparently gotten stale over the past few months due to a lack of maintenance, which has made CryptoSwitcher somewhat less useful.  This package doesn't try to do all of the things that CryptoSwitcher did, but what it does, it should do well.  Its workflow is roughly as follows:

• see what coins are tradable for BTC on Cryptsy
• check CoinWarz for profitability information (tested with scrypt coins, but others should work)
• find the most profitable coin to mine that we'll be able to trade for BTC
• call a shell script to switch pools, if necessary
• wait and repeat

You'll need API keys for both Cryptsy and CoinWarz.  CoinWarz charges for use of its API after the first 1000 calls; checking once per hour, you should be able to try out this script for six weeks before running out.

Grab it from https://github.com/salfter/coinswitch.  PyCryptsy is included as a submodule, so you'll want to grab it as well:

Code:

git clone https://github.com/salfter/coinswitch
cd coinswitch
git submodule init
git submodule update

See the README for further details.  coinswitch itself is in Python, but it calls shell scripts to do the actual switching, which can have their own dependencies.  (Mine depend on a PHP script I knocked together for use with CryptoSwitcher. For that matter, the shell scripts are the same ones I used with CryptoSwitcher.)

[Update:]

I'm looking into migrating my pool from mmcfe-ng to MPOS. It looks like I'll most likely end up having users create accounts on the new server, as I can't find information on migrating the old data to the new server.  That MPOS uses two password salts and mmcfe-ng uses one would probably keep old accounts from being able to log in.

I have a miner pointed at the pool, and shares are being accepted.  It's not found a block yet, but that shouldn't take too long for the coin I'm mining.  The bigger problem, though, is that when you go to the "my workers" page, it doesn't list any of the workers I have configured.  They're in the database, but nothing ever shows up here.  I've set $config["DEBUG"] to 5, but nothing useful is showing up in the logfile (yes, permissions on the logfile are correct).  Is there something I'm missing from the config that would get this working?  Is it a recently-introduced bug?  Looking at the SQL queries MPOS generates on access to the worker page, it looks like the pool_worker table is never queried...that can't be right, can it?

Update: The getuserworkers API call returns nothing as well, which suggests a common data source (for the webpage and API) that's not working as it should.

I first tried this about a year and a half ago, but got stuck.  I eventually got Armory working with the Gentoo LiveDVD, but that wasn't as desirable an environment (IMHO) as the SystemRescueCD (also a Gentoo derivative).  I gave it another shot over the past week, and I now have it working!

https://bitcointalk.org/index.php?topic=261318

With a big-enough flashstick (at least 32 GB at this point), you could put a copy of the blockchain on the stick, and keep your wallet in a TrueCrypt volume.  Put all of these in a SystemRescueCD backing-store volume and it wouldn't be much different than a normal install.

Today's news of the D Las Vegas and the Golden Gate accepting Bitcoin starting today kicked off an extended discussion on one of the local talk-radio stations. Kevin Wall (the host) and the rest of his staff sound like they're highly receptive to the idea.  They've been talking about it for about an hour.  I got on the air shortly after 5 PM to correct a previous caller's misconceptions about Bitcoin inflation, which led into a very brief discussion of mining, altcoins, and one or two other things before I lost the connection. :-|

If you're outside Las Vegas, go to their website to listen:

http://www.kxnt.com/

To get in on the discussion, call 702 733-5968.  They'll be on for another 40 minutes before their next show starts.

I have a Bitgem pool up and running:

https://bitgem.dyndns.org/

• PPLNS with 0% fee (for a limited time)
• Stratum only
• Email notification of dead workers, blocks found, and some other things
• Fairly comprehensive stats

It's running the PoS branch of stratum-mining-litecoin on the backend and mmcfe-ng on the frontend.  I also have a wallet generator (my bitaddress.org fork) and a block explorer (running CryptoManiac's Abe fork) available, as the other Bitgem Abe instance appears to not be maintained.

I've set up an instance of mmcfe-ng with moopless' stratum-mining-litecoin to get a Bitgem pool running.  One snag I've run into is with mining-income estimates.  The Bitgem block subsidy appears to have a bit more variability than some other coins (lately, it's actually crept up a little bit).  I know that the coinbasevalue entry in the output of the getblocktemplate RPC call is supposed to have the value I want (though it appears off in bitgemd by a factor of 100, but that's another matter), but calling getblocktemplate with no parameters can also return a bunch of transactions (especially with bitcoind) that generates lots of activity.  (For example, while the JSON-formatted output of bitgemd getblocktemplate currently returns only 603 bytes, comparable output from bitcoind getblocktemplate returns nearly 2 MB!)

This makes it look like getblocktemplate can take some options, but I'm having a bit of difficulty puzzling them out to see if I can get it to do what I want it to do.  If I could get it to just return a coinbase transaction without gathering up a bunch of transactions from the memory pool, that should run much faster and would be more feasible to call as needed to get the included coinbasevalue.  Is there some invocation of getblocktemplate that will do this, short of tweaking the *coind config file's block-generation parameters (which would most likely be a Bad Idea on a mining-pool rig)? It looks like sigoplimit and sizelimit might be able to control this, but whenever I try something like this:

Code:

bitcoind getblocktemplate "{\"sigoplimit\":\"-15000\"}"

the result is no different than without the parameters.  Is there something I'm doing wrong here?

I've ported the most recent version of the bitaddress.org wallet generator to Bitgem:

http://salfter.github.io/bitgemaddress.html

The bulk-wallet tab will produce compressed addresses, and the paper-wallet tab has revised graphics I knocked together.  I needed it while

Also, I have a stratum server up and running against bitgemd and am working on getting an mmcfe-ng instance talking to it.  I think this would be the first Bitgem pool since the closure (?) of btg.binarycoins.eu.

I've put up a customized version of SystemRescueCD 4.1.0 here:

https://dl.dropboxusercontent.com/u/57535575/bitcoin-sysresccd.iso

Some of what I've added to the image:

• Firefox
• bitcoind and bitcoin-qt 9.0
• Armory 0.90
• bfgminer (with support for most currently-available FPGA and ASIC miners...only one I left out was bfsb since that only runs on a Raspberry Pi)
• CUPS and HPLIP
• git

The main changes since the previous release (based on v3.7.0) are replacing cgminer with bfgminer and adding Armory.

If you install to a USB flashstick and add backing store, I suspect you could set up a diskless FPGA or ASIC miner with this.  With Firefox and printing support, you should also be able to create paper wallets and do other stuff you might want to do on an offline system.  All of the tools that come with SystemRescueCD are still in there, too.  If you add a copy of the Portage tree, you can even customize your system further (just make sure your backing store is large enough).

As you've probably already heard, BFL offered credit toward purchase of their ASICs for those of us who've been waiting for preorders to arrive.  I have eight available, worth a total of $200 off the purchase of eight ASICs, assuming you're willing to buy at least 100 (or go in on a group order).  I'm more interested in buying completed miners ready-to-go, though...besides, I don't have a reliable way to assemble BGAs and nobody's worked up an open-source miner around these chips yet (other than BFL, of course).  I'd rather have money to apply toward buying more miners.

Here's a screencap of my available credits:



I think BTC1 is a fair price...it's about 55-60% off of the value of the credits, at current exchange rates.  I've not done a huge amount of trading, but I have a #bitcoin-otc rating and a few purchases on Bitmit that have gone well.

While checking my TMDA pending folder, I found a couple of messages from the aforementioned outfit. One had their name in the subject; the other was titled "Bitcoin Master." They purport to have a 30 GH/s miner at (IMHO) an uncompetitive price. Anyone else heard of them? I'm not inclined to give spammers the time of day. Besides, I have a couple of Jalapeños that should leave BFL today, and some Avalon ASICs from a couple of group buys are a bit further out.

[Note:]

Is that altcoin you're considering more profitable than what you're currently mining? http://dustcoin.com/mining and http://www.coinchoose.com/ have some altcoins listed, but not all of them.  (For instance, neither of them have Yacoin listed.)  This little app I knocked together will tell you how much to expect:

https://dl.dropboxusercontent.com/u/57535575/CoinProfitability.zip

It needs these to do its calculation:

• interval over which to calculate (in seconds...86400 to calculate for a day)
• your expected hashrate
• the chain's current block reward
• the current difficulty
• (optional) exchange rate to get BTC for your altcoin

You most likely know your hashrate for SHA-256 and scrypt coins.  Difficulty is available from most block explorers.  Pools usually have the block reward available. Get the exchange rate from your favorite exchange; if you're calculating Bitcoin profitability, you can leave it blank or set it to 1.

You can now add configuration information to the registry for your favorite coins.  Example configs for several coins are included.  Adding others as you need them should be easy.  You can pull exchange rates from either Bter or Cryptsy (depending on whether they support the coin you want to exchange). Difficulty and reward information can be pulled from blockchain.info (for Bitcoin), most Abe implementations (for other coins), or from CoinChoose (for the coins it supports).

I built this in Visual Studio 2012 Express against .NET Framework 4.0 (needed that version because it's the first that includes BigInteger support).  I've also tested it under Mono; its implementation of Decimal.ToString() is a bit different and needed some adjustment.  Source code is also available...there really isn't much to it:

https://github.com/salfter/CoinProfitability/

Gnu.Getopt is needed to compile the CLI version:

http://getopt.codeplex.com/

Note: Exchange rates might not get looked up properly when running under Mono on Linux.  I might need to switch to a different JSON parsing library to make this work. I got rid of the dependency on JSON.NET that kept the calculator from running on Linux; it now uses .NET's JavaScriptSerializer class.

Update: (6 May 2014) Since scraping coin explorers is getting somewhat iffy, you can now use CoinChoose to get difficulty and reward information for the coins that are listed there.  Also, the library buffers data received from CoinChoose and Cryptsy for reuse, which speeds things up when you're (for instance) using the CLI to list all coins.

Update: (1 April 2014) Not an April Fools' joke: the CLI client has a new option to dump info on all coins.  Maybe this will run faster on the Raspberry Pi and similar resource-starved environments.

Update: (28 March 2014) Lots of changes.  First, Cryptsy changed the API URL a while back, but I hadn't updated this program. Also, the Litecoin explorer now returns block difficulty in the table on its homepage, simplifying data retrieval for that coin. I've also improved exchange lookup at Cryptsy...instead of downloading the entire orderbook on each call, it can download just the orderbook data for the currency in question.  Finally, proof-of-stake coins are handled properly: with Abe-compatible block explorers, we make sure we're pulling reward and difficulty information from the most recent proof-of-work block.

Update: (31 May 2013) A CLI version is now available for use in your scripts, as well as a DLL you can include in your own .NET (or Mono) projects.

Update: (4 June 2013) Cryptsy decided to start polluting its JSON with HTML...workaround applied.

Update: (4 June 2013, the second) Turns out that Cryptsy has an API now...that allows me to get rid of a bunch of cruft.

Update: (11 June 2013) Updated default config for more reliable operation, and added a Feathercoin config.

Update: (12 June 2013) Fixed a bug in which non-integer rewards caused an incorrect calculation, and added a Bitbar config.

This is just a quick sanity check, as I didn't find much on the matter that was definitive, but I want to make sure I'm doing the right thing with my deterministic wallet manager.

I wanted to implement support for compressed addresses.  I figured out compressed private WIF keys quickly enough: tack on 01 to the end of the private hexadecimal key and base58-encode it.  Handling of the public key wasn't as well-documented.  I tried looking at bitaddress.org and the Casascius address utility source for some clues, but the latter calls a library not available for this project and I couldn't quite make sense of the former.

If I have it right, it turned out to be nearly as simple:  split the public key (less the leading 04) in half and look at the last digit of the second half.  If that digit is even, prepend the first half with 02; if odd, prepend the first half with 03.  Push the result through the same hash and base58-encoding process to get the compressed address. 

Does this sound right?

Going the other way (from a compressed public key to an uncompressed public key) looks like it'd be much more involved, but I don't need that functionality for what I'm doing.

(If anyone's interested, the aforementioned deterministic wallet manager includes some Python code with no bignum or ECDSA dependencies that calculates addresses and private keys from hexadecimal private keys.  In its current form, it decodes to Bitcoin or Litecoin addresses, in either compressed or uncompressed format.)

I snagged a used 6870 fairly cheap about a week ago and have had it mining Litecoin, but thought I'd give Terracoin a spin as it's paying more.  However, I keep getting nothing but hardware errors.  I've downgraded the driver from 13.1 to 12.10, I've switched from Terracoin mining on P2Pool to Bitcoin mining on Eclipse, I've wiped out the settings and gone back to defaults.  Right now, my config looks like this, and it's still producing nothing but hardware errors.  The only change is to reduce gpu-threads to 1:

Code:

{
"pools" : [
	{
		"url" : "http://us1.eclipsemc.com:8337/",
		"user" : "** redacted **",
		"pass" : "** redacted **"
	}
]
,
"intensity" : "d",
"vectors" : "2",
"worksize" : "128",
"kernel" : "diablo",
"lookup-gap" : "0",
"thread-concurrency" : "0",
"shaders" : "0",
"gpu-engine" : "0-0",
"gpu-fan" : "0-85",
"gpu-memclock" : "0",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "75",
"algo" : "sse2_64",
"api-port" : "4028",
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "1",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "60",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

Temperature isn't skyrocketing out of control...in fact, it's lower than the ~80°C I was getting with Litecoin mining. What am I missing here?

(Underlying system is 64-bit Ubuntu Server 12.04 LTS...not my usual Linux flavor, but this box has the biggest power supply I have.  cgminer was built from source pulled from GitHub.)

I had been using Bitparking without any issues to speak of, but it's being shut down. Withdrawal fees at both BTC-E and Vircurex are both a rather excessive BTC0.01. To keep from losing too much to fees, I'd have to let a few weeks' worth of mining income pile up in an exchange account. Is there a more economical option for trading coins? Trading out to fiat currency isn't an issue for me; MtGox works well enough for that when I need it.