I believe this is the place to request a coin to be added. Please let me know if I am wrong or there is other information required: Thanks, Akroma Team. Actually the contact form is the right place for it, but I have made it for you and placed it into research queue. |
|
|
|
|
Before the change miners could mine erc20 tokens, which are still traded on exchanges, right?
Now everyone can mine mainnet quantum coins, but no exchanges to sell it onto?
Can you swap between erc20 and mainnet tokens?
|
|
|
|
I'm looking on DGB-Qubit (DGB) profitability calculator.
When I put 1000000.0 Mh/s (1Th/s), it shows daily reward as 0.086373 BTC ($710.65).
But when I put x10 = 10000000.0 Mh/s (10Th/s), it shows daily reward as 0.741514 BTC ($6,100.95).
I expect x10 power gives x10 reward, but it isn't the case.
Could someone explain those calculations?
Thank you and appreciate your feedback!
Same question as mikanoshi raised. WTM treats the calculation as new hashrate added to the network. @Mikanoshi Vast majority of people is using it as a way to predict the future. (attempt at least) Without this default, every calculation for a coin you are not already mining would be bogus. |
|
|
|
Rewards increase differently from hashrate increase which is best observed on small nethash coins.
How do you calculate that? And why it should be different? Imagine a low nethash coin of 100Mh/s, where 1Mh/s could be produced by just one card. You have 100 cards and throw all onto that coin. Nethash has just doubled to 200Mh/s, diff raised. You now have 50% of nethash, but before you did that it was a 100% of nethash. |
|
|
|
Hello, super noob SQL import question. I'd like to import the JSON output in to SQL, but I am struggling with the structure. I can select "coins", but none of the other headers seems available. Anyone done this that might have tips or pointers? Edit to be a bit more clear.I am struggling with the structure of the JSON output. Coins is declared as the top level, but then it gets tough to find the fields and headers so I can properly import them in to columns. Coinwarz is easy to import, but your data and site is MUCH better  Is this just the state of things or am I not referencing the JSON correctly? As a reference https://www.coinwarz.com/content/images/profitability-api-output.pngHey, this is based on ruby where you can have any json structure you want, cause its getting parsed as a simple nested hash with key => value pairs. Unfortunately its not possible to change the json structure now, hope you are good with your workaround @Mikanoshi All json calls without params will use the same defaults as seen in the UI. For coins and asic you can check those by pressing defaults and for single calcs - reset. Rewards increase differently from hashrate increase which is best observed on small nethash coins. "BTC", "LTC", "SC", "BCH" will use current diff for single calcs and the rest uses 24h average. |
|
|
|
It should mirror the difficulty and slowly go down with block reward.
estimated_rewards is just using current block reward instead of 24h average, isn't it?)
By default yes. That would explain the spikes. Need to rethink which coins need to stay on current and which ones to switch to 24h average. Will tweak this for sure. |
|
|
|
Chart is a mining reward in Aeon coins per day, based on estimated_rewards from API.
2.5% is a lot if only average values are used, especially when it just goes back to normal 15 minutes later.
We could check the data when the next spike appears, but please put the timestamp in utc onto the chart. |
|
|
|
BTG uses Equihash 144,5 aka Zhash, I call all 144,5 Zhash they differ only by personalization string So do you think BTG and other Zhash coins will be listed in whattomine as "Zhash" algo? Leaning towards renaming BTG to Zhash as well. This algo will be added to the list for sure. Just wish we had some stable amd miner. @whittle Not sure if you are saying or asking, but yes the links in the api docs are not working. Still not working. http://api.arabianchain.org/v1/dbix/main for example @Mikanoshi Price is not 24h average, but always using the last one, so that can cause that "spike" on your chart. Btw the chart is not in scale, this "spike" is just 2,5% difference. You can fetch profitability using 24h price average if you wish. Just need to feed the wanted value to the `er` param. |
|
|
|
If nethash drops in half then the diff will sooner or later drop in half as well, this is normal.
Same for increase. Thats why I prefer to look at profitability in 24h intervals.
Second line on chart is 24h diff and it's not dropping anywhere. How estimated_rewards from API is being calculated? Green chart is just this value over time. If it's based on average 24h block reward and difficulty it cannot suddenly drop 50% and go up 100% in the next half hour, but that's exactly what happens. I've seen it in another calcs, there it was block reward being detected incorrectly, switches to PoS or MN reward or something like that, and this last block reward value was used for mining reward/profit. Indeed for aeon there were stats with lower than usual block_reward (around 6). Thats odd cause the block_reward is fetched straight from the pool. This happened last time more than 7 days ago. Will be checking this in the future. |
|
|
|
Yes, mining reward for hashrate (it's in the legend ) I'm just saying that there shouldn't be any distortions like that, chart should be smooth. If nethash drops in half then the diff will sooner or later drop in half as well, this is normal. Same for increase. Thats why I prefer to look at profitability in 24h intervals. |
|
|
|
How have you tracked the block_reward?
Polling from WTM every 15 min Chart is for mining reward, but it depends only on diff and block reward, diff is changing smoothly, so there should be no such jumps. P.S. Dark mode is scary  Navbar is still white. Also try to reduce contrast between elements. So the green line is the reward mined with a certain hashrate? For me looks to mimic the difficulty swings perfectly. Thought you have plotted the block_reward as listed per block. |
|
|
|
Added dark mode switch in the top right corner. Is there like a profitability history?
Nothing like that for now. @mik Thats odd, block_reward for aeon should constantly and slowly go down, unless they changed the formula. How have you tracked the block_reward? |
|
|
|
Very helpful, great work, I just like your websites look and feel, simple yet easy to move around. It would be good if you mention the different ways of mining. Thank you.
Thanks @Mikanoshi Not sure what you mean, looks variable to me? |
|
|
|
I know SIA and all the other old usual suspects have been killed off for dual mining. I'm looking for keccak specifically for XDNA dual mining. Can you show me where ETH+keccak dual mining would be? The only options I see are decred, sia, lbry, pascal, blake2s, and sha-3. Claymore 11.8 supports it.
Try sha-3, that might be keccak in disguise  |
|
|
|
Is it 2^20 already? I will divide and use 2^13 that makes sense. What devs know  Its already updated to 2**20, but you wont get good results with 2**13. You said yourself that without any actions the api diff should work with 2**32. |
|
|
|
equihash formula Isn't equihash 2^13? P.S. Someone just dumped 200k CMM Profit halved. Hah so thats why I had to lower it to 2**12... Ok will show diff multiplied by 2**20 instead of 10**6 Thanks again @lexustop Normally no, but keccak is available on the coins list via those params: kec=true, factor[kec_hr], factor[kec_p] |
|
|
|
Why CMM diff is 8000 instead of 0.008 like node shows? Regular formula for reward with 2^32 should work. Spoken a bit with the coin dev and was suggested to use api_diff * 10**6 as coin difficulty + equihash formula. This diff is also returned by official explorer. @lexustop Trading service based on wtm? Not sure I get it 1. Default json response is for current default hashrates and powers. Would suggest to specify all parameters you need so they dotn change. 2. Not possible right now, will think about adding it to each coin response. 3. There is no list endpoint for Blake (2s). Verge is the only coin listed with this algo btw. |
|
|
|
@fredeq I calculated weighted average [SUM(diff * blocktime) / SUM(blocktime)] for many coins, it's higher than avg on WTM, even 17% higher for STRAKS It seems to be more accurate when network is under hashrate attacks: https://blockstats.pw/qbic/Without major hashrate jumps it's close to simple average (+5-10% max). Interesting, thanks for the details. Indeed it should show better results for coins with big hash jumps. Hmm will restore original timespan then for straks, avg was better for calcs before. To be honest I want to look into it more myself and crunch the numbers, but first need to deal with other stuff. Btw is that your website? pretty cool Can see you already added the weighted average, will be helpful. |
|
|
|
Honestly I am thinking that weighted average is the explanation here.
Simple average wont represent the data well, cause you can have many blocks stacked in short period with low diff.
How do you calculate weighted average? What blocks are more important than others?) If there are many blocks with low diff then next there will be blocks with much higher diff. Difficulty basically defines the expected number of hashes to mine a block, if nethash finds block faster or slower than target spacing then diff is adjusted accordingly. If diff retargeting is working correctly, simple average of all diffs will give very accurate number of hashes on a long interval. And 24 hours is pretty long, hundreds or even thousands of blocks. In other words taking all blocks from last 24h and calculating simple avg is not good or wanted.
It matters how long each difficulty period was mined for. You are polling diff each N minutes, what is your avg called? Absolutely random? The weighted average I was talking about would take into consideration how long it took miners to mine on certain difficulty. Time between blocks would just have been the "weight" summing up to 24h. If diff retarget is working correctly then your statement should be true - simple average should do the work. There are many coins where imo its not working as intended - or just cant handle the nethash swings. When you have those low diff periods on straks then the big hashes waiting for the drop will take majority of the blocks and leave after the diff raises up. About your second question. I believe that polling every N minutes simulates the "weighted based on time" average quite nicely. Why? Cause the estimated rewards just match what I have mined for the last 24h. Afterall thats all that matters. If I was to name it then "Normalized time spent mining average difficulty" would be close. For sure we dont want a simple avg here and the 24h value on wtm should not be interpreted as one. @whittle @nitro3 Last time I asked dbix devs about working apis for network stats I got no response. Honestly listing invalid api urls on official website does not inspire confidence. Guess I will wait for the apiv2? Or the old apis are back online? @Mikanoshi BTCZ calc updated with new algo |
|
|
|
|
Show Posts
