Read-only forum archive. PROHASHING has closed. Posting, registration, and account access are unavailable. Preserved from the April 3, 2026 server backup.

Earnings today 8/26

zxzxzx
Archived posts: 13
Joined: Jul 19, 2015

Earnings today 8/26

by zxzxzx · · Post #2019

Hi Steve,

I'm not sure but I think have an issue with today's earnings. I have a Titan that hashes between 300MHs to 340+MHz (accepted hashrate)
When calculating 300MHz (low estimate) x 0.00027522 my earnings should be over 0.08 BTC but I only got 0.06004762 today.

Not sure if it is related but, I had 20% and 50% of the payout allocated to LTC yesterday (8/25) and the day before (8/24) but I changed LTC to 0% yesterday around 6pm PDT before 9pm PDT payouts.

As of yesterday I have 100% of the payout allocated to BTC in the setting.

Thanks
ZX
Ben44
Archived posts: 9
Joined: Aug 27, 2015

Earnings 8/26 and 8/25

by Ben44 · · Post #2020

I'm having the same problem with my not so well running two Titans which have about 500 MHs combined since weeks but yesterday I've earned only 0.08497336 BTC (Payout on 27.8.2015) and the day before only 0.13820396 BTC (Payout on 26.8.2015).

Thanks for your help!
Steve Sokolowski avatar
Steve Sokolowski
Archived posts: 4559
Joined: Aug 27, 2014

Re: Earnings today 8/26

by Steve Sokolowski · · Post #2030

OK, I think I got to the bottom of this problem.

This is a complicated answer. About six months ago, we realized that we cannot compute an exact daily earnings estimate because that would require looking through tens of millions of shares. We turned off that query and replaced it with another query. There's no need to try to understand the code, but rootdude might appreciate it:

Code:

	select (select sum(usd_equivalent_value) INTO AVERAGE_EARNINGS_BTC from status_miner_daily_balance
	where date=start_date_in) * 1000000.0
	/
	((select avg(accepted_hashrate) from status_hashrate where status_hashrate.start_date>=start_date_in and status_hashrate.start_date < end_date_in and accepted_hashrate is not null and accepted_hashrate <> 0) 
	*
	(select avg(price_in_usd) from history_bitcoin_exchange_rate where originally_created >= start_date_in and originally_created < end_date_in and price_in_usd is not null));
It says that earnings are equal to (total money earned) / (average hashrate). The best way to interpret this is "the rate an average miner mines at." It's different from "the rate a miner who stays 100% of the time mines at" because even if one miner leaves and returns, the "average miner" is no longer someone who mined 100% of the time.

The reason these estimated numbers have been strange the past few days is because the litecoin block halving caused lots of miners to come in when profitability was high and leave when profitability was low. On most days, the "average miner" stays for most of the day. Fortunately, I was not able to detect any actual problem in payouts. We lost about 5% due to slippage on Tuesday, so miners got the good end of the deal.

We apologize for the problem. We knew that the numbers could be up or down by a small amount, but we didn't know how far off it would be when this halving occurred. I'll spend some time tomorrow seeing if there is an alternate way we can compute profitability now that the greater hashrate is messing with our numbers. We already know how to get an exact number, but the performance of the "exact number" query is too low.
Steve Sokolowski avatar
Steve Sokolowski
Archived posts: 4559
Joined: Aug 27, 2014

Re: Earnings today 8/26

by Steve Sokolowski · · Post #2034

I was able to figure out how to get exact earnings from a query that runs in about 110s. The changes will be available in the next release. For those interested, the solution was to disable table scans by using:

Code:

SET seqscan=off;
I tested this code and for yesterday, it came back with 3.943 cents, which is a 2% difference from the 3.99 cents that the estimated query provided. The BTC query was further off, because it used the estimated USD value and then divided by the average BTC price. It was off by about 5%. These new queries are also far more accurate because they don't provide ideal numbers; they provide what a miner with an average work restart interval earned.

Expect to see these changes in the next release! Thanks for the report that helped us resolve this issue.