So if you follow all the cryptocurrency stuff (which you must or why would you be reading my blog?), you're certainly familiar with Coinwarz and Coinchoose, and maybe you even try to decide what to mine based off of their charts. There are a couple major problems with that approach unfortunately: first, tons of other people (and multi-pools) are basically doing the same thing; second, you're inherently limited in what coins you can mine as neither pool comes close to listing every current cryptocurrency.
Take Vertcoin, Microcoin, Darkcoin, and Maxcoin as four prominent examples. Whether or not you believe any of those coins have merit, the fact is that they don't use scrypt or SHA-256 algorithms and are not listed on any of the major "which coins should I mine?" sites. So how can you determine the approximate profitability of those coins? More importantly, how can you determine the profitability for pretty much any cryptocurrency? Well, there's a way, and short of someone modifying a core aspect of the code to change things up it's not too difficult. Ready for this? The number of coins per day you can expect to mine with a given hash rate can be expressed with the following equation:
Computers work in binary digits -- zeroes and ones -- so when we talk about the number 100, a computer doesn't represent it as two digits; instead, it would use seven digits, called bits, and 100 would be represented as 1100100 -- or to help people know that we're talking about a binary number, we would write 0b1100100. Of course, writing out just zeroes and ones like that isn't always super useful, and so we have hexadecimal notation, with "digits" of 0..9 and A..F.
Any programmer already knows where I'm going, but the short summary is that hexadecimal allows you to use one character to represent four binary digits (bits). The denominator within the denominator is in hex notation, 0x00000000FFFF.... If you count the number of characters in that string, there are 64 (eight zeroes, four F's, and then 52 more zeroes). In binary, that big long hex number would be even longer: 32 zeroes, sixteen ones, and then 208 more zeroes. The problem now is finding a way to deal with those big numbers.
If you pull up the Windows calculator as an example, we can calculate 2256, and it gives us: 1.1579208923731619542357098500869e+77. As you might expect, there's a loss in precision with that "e+77" part. The second number is a bit more difficult to deal with. 0x0000000FFFF.... ends up being the same as sixteen ones followed by 208 zeroes in binary, which is the same as:
2208 + 2209 + 2210 + ... + 2222 + 2223, or if you prefer it's: 2224 - 2207 - 1 (I thnk?). There's still a loss of precision however, as the result is 2.6959740979080974643911745715872e+67 (so we're missing about 37 digits worth of precision). Just running that calculation in the Windows calculator, however, we can make a substitution and the result becomes (the number is a bit off, but it's okay):
But enough talk. You probably don't want to create your own Excel spreadsheet, and I don't have the inclination to try and write a web application that will pull down the information for an arbitrary coin. If you want an estimate on the number of coins -- of any cryptocurrency! -- however, I can help. If all goes well, the form below should do what you need; it's messy but still potentially useful. I personally like having something like this because it's usually very easy to find out the current difficulty and block reward for any cryptocurrency, but sometimes determining things like network hash rate is not so simple. Note that I didn't try to account for electricity costs, mining pool fees, or exchange fees.
Cryptocoin Mining Calculator |
|
| Hash Rate | |
| Difficulty | |
| Block Reward | |
| BTC Rate | |
| BTC Price (USD) | |
| Coins per Day (Month) | 0 |
| BTC per Day (Month) | 0 |
| USD per Day (Month) | 0 |
Fun facts for current profitability (determined using my awesome calculator):
DRK (X11 PoW for CPU mining) will generate about $3.75 with a Core i7 CPU
MAX (SHA-3 kekkac PoW) will generated about $5.95 per day with a Radeon 7950
MRC (scrypt-jane alternative PoW) will generate about $7.70 per day with a Radeon 7950
VTC (adaptive-n-factor PoW) will generate about $7.30 per day with a Radeon 7950
Donations as always are welcome:
BTC: 153qS9Ze32hnV3fwirZLWNka4wBAowc21E
DOGE: DD9iTWf8diPkvKdB8roPJepTyp6BGVQtct
DRK: Xd3EaCJg6G8ZnGuKkpvwyRMwyHzbaRDnob
MAX: mf5DXTLiZFCnJC2x13MXSyigyUjmBnrwjG
MRC: 1Ctnz6cHcMYiF9fz2pyd6orFuo1mDhKdWj
VTC: VaNuRCj73JVAwR1YMnt8CXaqoiPgykiMTk
Thanks for that!
ReplyDeleteLoving the mining blog posts, you really now what you are talking about and seeing the trends.
ReplyDeleteWhere are (would you) selling your DarkCoin? Still here:https://c-cex.com/index.html?p=drk-btc?
I'm still holding mine, as the price is still trending up, but C-CEX is where I monitor the DRK price, but you can also trade on Poloniex: https://www.poloniex.com/exchange/btc_drk
DeleteHi. I don't understand what valour take the parameter "seconds" of your equation, neither where it is in the Cryptocoin Mining Calculator, can you explain pls? I am really interested in my own Excel spreadsheet.
ReplyDeleteI hard-coded in 86400 seconds for a day (and 2592000 seconds for a month) for my calculator. If you're doing it in Excel, it would just be:
Delete[seconds] * [block reward] * [hash rate] / (difficulty * 4295032833) = Coins
And then Coins * BTC rate = BTC per day
Ok, then block time (i doubt about it) is not a parameter for this ecuation. Thank you very much.
DeleteCorrect -- the block time is already accounted for in the difficulty factor. Difficulty for each coin is calculated to target a specific block time, and it will scale up/down to do so.
DeleteIn the case of LTC it's supposed to take 3.5 days per 2016 blocks, with a block found every 2.5 minutes on average. Let's say difficulty is 100 and instead of taking 3.5 days it takes 3 days, then the next difficulty will be 16.67% higher -- 116.66667 -- in order to bring the average block time back to 2.5 minutes. Or if it takes 4 days instead of 3.5 days, then the difficulty would drop 12.5% -- to 87.5 in our example -- to bring the block times back to 2.5 minutes on average.
Sorry, still no sense at all. What is "seconds"? Time to solving a block? Time to retarget diff? Why do you hard-coded 86400 seconds? That's a day duration, nothing to do with any coin, block time or anything. Could you please give us a *SPECIFIC* example using your ecuation, Maxcoin for example?
Delete"seconds" is how long you mine and the equation calculates the expected reward for that time. Of course, if you mine solo you only get a full block reward or nothing, so the equation is an estimate of the chances of you finding a block.
DeleteSo with Maxcoin, current difficulty is 101625, and the block reward is 92. With a system producing 1000 MHash of keccak mining performance, you would on average find 18.2 MAX per day. But you can't if you're mining solo, so instead you would statistically find a block of 92 coins solo mining every 5.055 days -- except statistically, you'll probably average out to lower than that as pools are more likely to find the blocks with their superior hashing numbers, so maybe you find a block every six days.
You get those numbers from my calculator, which hard-codes in 86400 seconds. If you were to mine MAX for only one second, you would earn 0.000211 MAX in theory... or your chances of finding a block of 92 MAX mining with 1000 MHash for one second are 1 in 436747 (give or take). In other words, mine for 436747 seconds with 1000 MHash and statistically you should find one block. If we could free the network hash rate (and thus difficulty), over the course of a year that would average out just about right. On a day-to-day basis "luck" is a factor, but long-term it should even out.
Thank you very much! I looked a long for a math formula to calculate coin profit per MHash but I didn't succeed. Good mining to everyone!
ReplyDeleteGreat tool! What a good idea! :) Next question is where do you find the coins that haven't yet hit the exchanges?
ReplyDeleteyeah good postings. good ideas to bring more readers here. good to have a place to compare my own thaughts..
ReplyDeleteover last two days mining on local p2p node I got 196196.49 leafs. 3000 kH/s. using your calculator I should have this with only 1000kH/s.
do you have ideas how to add total pool hash rate and your hash rate to know your chances?
The current block reward for LEAF is 1-500000 (it dropped from 1-1000000 at block 15001), so on average the reward will be around 250K. However, there's luck involved so you could get poor rewards averaging 200K for a day, especially when looking at just one pool, and if the pool gets doubly unlucky and only finds 60% of the expected blocks in a day you end up with some bad days.
DeleteThe past 24 hours LEAF has average 44 difficulty, so with 3MHash you'd expect ~342890 LEAF mined. But subtract 2% pool fees, add in 20% bad luck for rewards, and another 25% bad luck for your pool for the day, and you'd end up with around 200K LEAF instead. What's your pool, and what's the pool hash rate?
http://rav3n.dtdns.net:9166/
Deleteedit: not total poolrate, but total net rate
DeleteLooks like that pool is about dead? Anyway, if you took the pool hash rate and use the calculator, you can determine how many coins per day the pool should find. Then take your percentage of the pool's rate (minus pool fees, where applicable) and you get the number of coins you should receive from the pool.
DeleteThis comment has been removed by a blog administrator.
ReplyDeleteThe BTC rate is whatever the best exchange rate is for the coin, so you need to look at the various exchanges -- BTER, BTC-E, CoinedUp, CoinMarket.io, CryptoRush.in, Cryptsy, etc.
DeleteI am trying to understand this formula with units, as adding units would greatly increase my understanding of how this works. I think that 1 share = 1 block reward. Is that correct?
ReplyDeleteThat would make the units on top ‘seconds’, ‘coins/share’ and ‘hashes/second’.
The bottom looks tricky. . If I understand it correctly, there are 2^256 hashes per share, with one share equaling the block reward. The number 2^256 would be the number of hashes required for a share, so ‘hashes/share’. Do the numbers for ‘difficulty’ and ‘0xFFFF[52 zeroes]’ have units that cancel? Or are they just used as a constant to keep the block time the same? Or perhaps I am missing or misinterpreting part of this.
Don't think in shares or units -- those are only figures you'd get from a mining pool. I believe if we put units to everything:
DeleteTime = second
Reward = coins / block
Hash Rate = hashes / second
Difficulty = hashes / block
So it would be:
t [seconds] * r [coins] / [block] * h [hash] / [seconds]
----------------------------------------------------------------------------
d [hash] / [block] * z
When you cancel all the units out, you're left with coins. The only oddity is that "z" -- the big number that's basically used to scale the difficulty by 4295032833. This is one of those "what is this number?" things, that's not really documented in the code, but presumably it's a value chosen that makes the scaling work. Maximum difficulty is something like 2^220 incidentally (meaning, difficulty times that scaling factor needs to be able to fit in the 256-bit integer).
I'm a real formulas kinda' guy. When I see something like this I want to know how it was put together, and have a real talent for understanding formulas. 2^256/0xFFF[52 zeroes] means something, I just haven't figured out what that is. I'm probably going to have to get a good cryptography book to understand it to my satisfaction. Know of any good ones?
DeleteWell, it's basically a minimum difficulty setting. We're dealing with 256-bit numbers, so take the maximum value you can represent with 256 bits (2^256) and divide that by0xFFFF (+ 52 zeroes) and we get 4295032833 (and a few decimals that aren't worth mentioning). Given that we're targeting "hashes per block" with the difficulty, that means a difficulty of 0.000000000233 would result in you generating [reward] * [hash rate] coins per second. If difficulty on the other hand is 1.0, then you need to perform around 4,295,032,833 hashes per block, so at 1MHash/sec it would take around 1.19 hours on average per block. Basically, it's a scaling factor.
DeleteWhy not just use difficulty on its own and forget about this scaling factor? No idea -- part of me just thinks it's because the programmers like being "clever". In the case of Litecoin, of course, it works out that your hash rate in KHash/s divided by difficulty currently estimates your number of LTC per day.
On a related subject to my question, does WU have units besides just 'per second'?
ReplyDeleteWU is simply something you get from cgminer and other software, and it doesn't really have any useful meaning. A pool can give out units of work that are easier or more difficult based on your hardware speed. This is called "vardiff" -- variable difficulty. The idea is to not use any more network bandwidth or server resources than necessary, so a fast system will get something like 1024 difficulty shares while a slow system might get 16 difficulty shares. One diff 1024 share is worth 64 difficulty 16 shares, and if the hardware in the one system is 64 times as fast then both systems will complete one work unit in about the same time.
DeleteWait wait...then WU value doesn't matter? Testing settings, is better more kh/s than wu? I have read that a high WU value is the most important target, even if you need to low the kh/s, in so many sites/blogs/forums...I'm so confused right now :S
DeleteWell, they should be more or less equivalent, provided they're on the same pool. Let me give you an example:
DeleteSystem 1: 1.366 MH/s, 1251 WU/m
System 2: 0.299 MH/s, 265 WU/m
System 1 is more efficient (915 WU per MH vs. 886 WU per MH), but since it's faster that would make sense -- it gets work restarts a bit less frequently. But if you're on different pools, the value of a WU may not be the same. Definitely don't try looking at units (U), though, as most pools with vardiff try to get to roughly the same Units per minute -- this is how many "getwork" requests your system sends. So I suppose my initial answer wasn't entirely accurate, but optimizing for WU/m is a bit difficult as it's usually dependent on many factors -- pool, coin, block target time, etc.
Yes, but im not talking about differents pools or coins or rigs. A real example: in the same pool, im playing with overclock, and sometimes get more kh/s but less wu (with enough running time to mitigate luck factor, 12h or even better 24h), i thought a higher WU was always better in this scenario, i'm wrong?
DeleteIf they're both on the same pool, same type of GPU, same everything... well, sometimes there's still variance. It just happens as part of the way things work in my book. The primary GPU also seems to often run slower (as it has to run the Windows UI among other things), so keep that in mind.
DeleteI have a 3-way rig running 7950 as an example, and right now GPU 0 is showing 3.05 U/m while GPUs 0/1 show 3.25/3.23 U/m. They're all running on the same pool, with the same instance of cgminer. GPU0 actually has higher clocks (1000/1475), while GPU1 is 975/1475 and GPU2 is 950/1425. So GPU2 is doing 5.9% more U/m after more than a day of mining, while GPU0 actually has 5.3% higher core clock and 3.5% higher RAM clock. And if I change the clocks on GPU0 to match GPU2, performance of GPU0 will drop even more.
TL;DR: Don't get too hung up on variance between GPUs of 5%, as it's just the way things go with mining.
"[WU] doesn't really have any useful meaning" This is incorrect. If you let cgminer run for a while, WU can be used as a better estimate of your kh/s. It runs about .92 of the kh/s that cgminer shows (disregarding units). This is the reason I wanted the units for WU...to determine what the ratio should be to a more accurate degree.
DeleteAs far as the equation above is concerned, there is no place to include "WU". The equations take difficulty, hash rate, block reward, and the number of seconds you mine into account. WU is none of those items.
DeleteWU is basically a figure you get from cgminer that represents how many Work Units you are processing per minute, with a WU being somewhat similar to your hash rate. However, your WU values will change if the VARDIFF setting from a pool you mine on changes -- you can see this when you start up cgminer (or bfgminer or whatever) and a pool might start you at a WU difficulty of 16 and then scale that up over the first 5-10 minutes until the WU difficulty is 256, 512, 1024, or in some cases non-powers-of-2 are supported by the pool. So in effect, there's no way to convert WU into hash rate unless you have a static pool difficulty setting -- or you integrate over how long you mine at each difficulty setting I suppose.
As noted already, WU represent the accepted work units you have sent to a pool, but it is prone to more variance and "luck" than pure hash rate. Unless you are 100% of a coin's hash rate, you will never have 100% accepted hashes, shares, WUs, or whatever. So the above equations can at best provide the estimate of your income. If you want to multiply by 0.92 to account for stales and such, yes you can do that. But at best your WU rate vs. your hash rate is only going to tell you how "lucky" you have been on this particular coin/pool.
And as an aside, this is why shorter block times are actually not a good thing in terms of miner efficiency -- people don't have nearly as many stales/work restarts on coins like BTC, LTC, VTC as they do on a coin with a 30 second block target. And when a new coin is launched with a "bad" starting difficulty, the first several hundred or even several thousand blocks can be mined in a matter of minutes, with 99% of your work being "stale" due to the too-short block times. So nearly everything ends up as an orphan until the difficulty reaches a suitable level to stabilize things.
The hashrate given on cgminer and on a pool's website are both estimates. WU is based on actual shares submitted and is a more stable figure once you let your miner run for a while. If you let your miner run for a day, your WU will hardly change at all while the kh/s will still fluctuate up and down.
DeleteI'm getting closer to the answers I'm looking for; part of the equation has been rearranged. This article has helped get me started.
In my example, I was talking about global average hashrate and global WU, no about differences among cards. Anyway i think Jon Hall is right, at least this is the behaviour i saw in my rig so many times (now im getting exactly a 0.916 ratio after 72h in the same pool)
DeleteAnd this is kinda' my point. That ration is the same for any non-modified scrypt pool (no N-scrypt, maxminer, etc.). And since it is the same across many websites and many coins, there is a reason for it. There is some math behind it and I want to know what it is.
DeleteCan anyone explain how exactly is the (block reward) number calculated? Any logical explanation of an algorithm?
ReplyDelete