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.zipIt 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. |
|
|
|
I bought a 6870 from a seller on Bitmit a couple of months ago...been running like a champ ever since. It's good for about 310 MH/s (sha256) or 300 kH/s (scrypt). The only transaction where I had trouble was for some RAM for my mining rig; after the seller refused to ship for two weeks, I fired off a request to Bitmit and got my coin back. |
|
|
|
Bitburner  This sounds nice, but it needs some German flair.. Maybe BitSchnitzelBurner. One minute with Google and two minutes with the Gimp produced this:  |
|
|
|
It would be nice, but there's no way to deposit NMC. http://bter.com/myaccount/deposit/NMC returns an error. Hopefully it's a work in progress, as I'd need to mine a ton of NMC to make exchanging them at BTC-e or Vircurex feasible wirh their high BTC withdrawal fees. |
|
|
|
I dug around in the vanitygen code a bit and got it to spit out compressed addresses without too much difficulty. I've put my fork up here: https://github.com/salfter/vanitygenAs an added bonus, it'll generate Litecoin vanity addresses (compressed or uncompressed)... How do I compile that? or are there windows binaries already available? git clone https://github.com/salfter/vanitygen
cd vanitygen
make vanitygen
This might works under Cygwin, but I've not tried it as the machines on which I run vanitygen all run Linux...you might need to pull in the PCRE and OpenSSL headers if you don't already have them. Of course, you also need git, gcc, and make. For git to work with HTTPS URLs, you also need the ca-certificates package (why this isn't pulled in as a dependency of git is anybody's guess.) Attempting to build in Visual Studio is likely to be painful. (Edited to reflect a successful build under Cygwin.) |
|
|
|
Hi all. I'm really surprised that vanitygen hasn't switched to generating compressed keys.
Uncompressed keys have public keys about twice the size of compressed ones and this means that when you use vanitygen produced addresses you end up paying more in transaction fees, causing more increase in blockchain size, etc.
I have modified my own copy of vanitygen to produce compressed keys...
Please upload your version of vanitygen. We will all be grateful for it. Put a disclaimer on your version if you don't like support or whatever, I am sure it will work just fine as is if the only modification was making it produce compressed keys. AFAICT, he never did. I dug around in the vanitygen code a bit and got it to spit out compressed addresses without too much difficulty. I've put my fork up here: https://github.com/salfter/vanitygenAs an added bonus, it'll generate Litecoin vanity addresses (compressed or uncompressed). Since I'm not sure if script addresses can be compressed, I made script addresses and compressed addresses mutually exclusive. Use something like this to get a compressed Bitcoin address: vanitygen -F compressed 1 To get a compressed Litecoin vanity address, use something like this: vanitygen -LF compressed Lfoo I've checked the generated addresses against bitaddress.org and liteaddress.org; it looks like it's doing what it should. |
|
|
|
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 have 13 chips on order. The Klondike board looks like it'll be set up for 16. Does anybody have 3 chips to unload?
|
|
|
|
TL;DR: You can cash most coins out. BTC-e.com, bter.com, and vircurex.com will convert your alt coins back to BitCoin.
Of these, bter.com would appear to have the most favorable fee structure. The others charge BTC0.01 to withdraw; bter.com charges only a tenth of that. Bitparking offered the same rates...too bad it shut down. GPU isn't dead for Scrypt Mining.
Indeed. While waiting for BFL to deliver, I picked up a 6870 off of Bitmit. I've only had it running a month or so, but at BTC0.7, I think it's already paid for itself.  |
|
|
|
I figured out what I was doing wrong: when I set up this box for mining, I had installed the latest AMD APP SDK, which is v2.8. From the cgminer README: Q: Which AMD SDK is the best for cgminer?
A: At the moment, versions 2.4 and 2.5 work the best for R5xxx and R6xxx GPUS. SDK 2.6 or 2.7 works best for R7xxx. SDK 2.8 is known to have many problems. If you are need to use the 2.6+ SDK or R7xxx or later, the phatk kernel will perform poorly, while the diablo or my custom modified poclbm kernel are optimised for it.
Derp. I tried installing 2.5 since I have a 6870, but cgminer (whether using the prebuilt binary or one I built from source) segfaulted a second or two after startup. I think it was a libstdc++ conflict of some sort. As things stand now, I have v12.10 drivers, v2.6 APP SDK, and v5.0 ADL SDK installed, and cgminer 3.1.0 built from source. I let it mine against EclipseMC for a few minutes...saw that it was getting a few shares accepted. Since other coins are currently more profitable to mine, I'm not currently mining Bitcoin...but if the bottom falls out of the different altcoins or if an sha256 altcoin becomes more profitable than an scrypt altcoin, I can switch over to that now. One thing I noticed: the fan runs at a much slower speed when doing sha256 mining. While keeping the GPU at about the same temperature, the fan was running at about 1600 rpm or so. Doing scrypt mining, it usually runs at about 3400 rpm. Temperature is about the same either way: 65-67°C in a cheap midtower case with the lid off (lid on raises the temperature to around 80°C). The fan on the 7750 in my main mining rig behaves similarly: fan runs (IIRC) at about 40% or so when doing sha256 mining, but at 85% when doing scrypt mining. |
|
|
|
You guys also need to get better dealers $2+ over spot is fairly expensive, you need to be around $1.5 or lower.
I ran across this last night: http://www.zerohedge.com/news/2013-05-01/silver-just-179-over-spot-there-one-minor-catchThose who have been following the barren wasteland that is the precious metals retail market know that not only is it virtually impossible to get any silver for less than a $3-4 premium per ounce over spot, but it has become next to impossible to find any physical, period. So the fact that Apmex is now selling silver at just a $1.79 over spot - a bargain even in the days when JPM wasn't about to run out of commercial gold (incidentally no change in the gold held at the firm's 1 CMP vault as of yesterday's close), and certainly a blue light special at a time when the entire world is scrambling for anything shiny. There is however one minor catch. Maybe not so minor. Because while most PM afficionados are used to buying silver by the ounce, or at most bar, the Apmex offer involves a very generous dollop of Silver Koala. 1 Kilogram's worth of generous.
|
|
|
|
AFAICT, the only thing likely to get it running again is to redownload the blockchain. I moved .litecoin to a safe location, created a new .litecoin directory, copied over my litecoin.conf and wallet.dat, and am now letting litecoin-qt pull in the blockchain again. It's set to only talk to the litecoind on my mining rig, so the transfer's only running across the LAN and should be done in less than a half-hour. It's halfway done as I write this; if it ends up working properly, I'll do the same thing with bitcoin-qt.
As a bit of follow-up, this method worked. It took a little longer to pull the Litecoin blockchain through (and it took a few hours to rebuild the Bitcoin blockchain), but it beats having to download them from outside the LAN. |
|
|
|
Wow I just made a post regarding this. I'm also about to leave this pool. Problem is iv been mining for almost two days now and I'm so close to a payout. It's not even funny. Who do you guys recommend for ltc?
So far, wemineltc.com looks promising. Payout so far is consistent with the hashrate I'm giving them. I'm splitting time between them and fcpool.com...same algo, and Feathercoin looks like it's about 2x more profitable for now. |
|
|
|
I've just spent 2 days mining LTC at pooledbits.com and not a single reward has turned up. about 400khs as well. Anyone else have the same trouble?
I tried it out for 24 hours with about 460 kH/s. The indicated per-share rate for most shares was ridiculously low (a handful of satoshis). The shares completed indicated on their website appears to have a somewhat loose relation to shares reported completed by my miners. Combine those with a lack of an official presence here or in the Litecoin forum...at this point, I'm inclined to cut my losses and switch to another pool. |
|
|
|
come on guys 170 views and no one has even a slight CLUE?
I have a 6870 in an Ubuntu server, with cgminer 3.0 and Catalyst 12.10. This configuration has worked well on several pools...currently trying out WeMineLTC: {
"pools" : [
{
"url" : "stratum+tcp://eu.wemineltc.com:3333",
"user" : "**redacted**",
"pass" : "**redacted**"
}
]
,
"intensity" : "15",
"vectors" : "1",
"worksize" : "64",
"kernel" : "scrypt",
"lookup-gap" : "2",
"thread-concurrency" : "4480",
"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",
"api-port" : "4028",
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "1",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"no-submit-stale" : true,
"queue" : "0",
"scan-time" : "60",
"scrypt" : true,
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}
For your 5870, this suggests that you might want to stick with Catalyst 12.8. Also, you'd probably want to bump thread_concurrency up to 6400. Make sure kernel-path is correct for your system (on my Gentoo miners, for instance, /usr/lib/cgminer is the correct value). My 6870 delivers about 290-300 kH/s with this config. |
|
|
|
|
Had some issues with passwords generated by LastPass that would fail silently...tried using passwords such as A3t&5n9Cn8T6tJ%y@eMV^J@F and JGX9jPx5XtsRKzBukr5RtjuuZwfFbEPx, but was unable to log in. I finally got it working with a 16-character password with only letters. If you're going to impose arbitrary limits on password strength, it would be best to specify those limits wherever a new password is requested.
|
|
|
|
Got my email...am OK with the Jalapeņo needing a power supply, as it makes any USB power concerns moot. My only concern is how long it'll take them to get to late-August orders like mine.  |
|
|
|
|
Show Posts
