Whattomine - profitability website with basic json.

[fredeq]

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

[1714817731]

1714817731

[1714817731]

1714817731

[1714817731]

1714817731

[Mikanoshi]

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.

Same on XSH, so profit for regular miners is 2-3x less than the calculated value.
You cannot take this into consideration because it's random and actually one miner gets the correct calculated rewards

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.

I get it, belief and coincidences. Sorry, but simple average will remain the only reasonable way for me to calculate theoretical rewards that can be compared to each other, until someone shows a better mathematical method. Currently no profit calc has all the correct average difficulties.

[nitro3]

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?

Apis are already out there, developed by community, and used by all pools


@Mikanoshi
BTCZ calc updated with new algo

[Mikanoshi]

@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).

[fredeq]

@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.

[Mikanoshi]

Why CMM diff is 8000 instead of 0.008 like node shows?
Regular formula for reward with 2^32 should work.

[fredeq]

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.

[Mikanoshi]

equihash formula

Isn't equihash 2^13?

P.S. Someone just dumped 200k CMM Profit halved.

[fredeq]

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]

[Mikanoshi]

Is it 2^20 already? I will divide and use 2^13 that makes sense. What devs know

[fredeq]

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.

[Mikanoshi]

Yes, I confused myself)) I'm using 2^32.

[arzunpathak]

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.

[Mikanoshi]

Aeon and Loki. Do they really have variable block rewards? Aeon looks more like a bug

   

[fredeq]

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?

[Mikanoshi]

Not that variable. That chart was using current reward, not the 24h one. Is it really dropping 2x from time to time on Aeon for example?
Because this is a formula from the readme:

Code:

Block reward: Smoothly varying using the formula ((2^64-1) - A * 10^12) / 2^18 / 10^12 where A = supply mined to date

2x drop is not very smooth The only variable that is not constant () there is mined supply and it cannot just jump back and forth to halve the rewards for some blocks.
Must be wrong value taken as a reward, txes on that cn coins are weird.

[CryptoCoin101]

Is there like a profitability history?

[fredeq]

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?

[Mikanoshi]

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.

[fredeq]

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.