█▓▒░-< [ZPOOL.CA][BTC Multipool] The miners multipool >-░▒▓█ Paid 925+ BTC

[jkminkov]

for all my rentals they have usually rented at 0.0044-0.0048 or so;  spending ~26mBTC.  Generating 19-21mBTC after the rental is up....  which is close to the amount the share reports are off by;   and thats also with an extra S3 running that consistently generated 2.2mBTC/day.

The hashrate reporting is almost nominal;  within a few percent; so I know those per-share hashrate calcs are good =)

sorry you pay 26 mBTC for earn 19-21?

yes.

Each time I calculated based on profitability reports from the pool through the day;  the estimates should have been to earn 1-3mBTC after 24 hours.    They obviously kept falling way short.   Even on a days when rental was a lot cheaper than the previous day.

I have a nagging suspicion it has to do with the major difference between pool hashrate % and share reward % that I can see on my zpool wallet page.

I expected to loose out from the start;  so I wasn't disappointed if I did loose coin;  its not that much of a loss to help the pool try and see if there truly is an issue with the calculations somewhere.

I just dont have any way else to explain away the difference between pool hashrate % (on left side where total share amount from each algo is displayed), and the share value of the coins on the right pane where it lists found blocks and credit for them.

Example:

if you check api you will see that site reports actual_last24h values under profitability, better take note on estimate_current and estimate_last24h also, as for % own hashrate towards % pool hashrate, try lowering share diff, the shorter block round is more random % of own shares are as your miner take some time to submit shares and may miss a block, but in next it can submit two shares instead but even if you fix your shares workflow other pool miners and share luck also change. you can use stratum proxy to track your S3 hashrate https://github.com/Stratehm/stratum-proxy

[AngryDwarf]

for all my rentals they have usually rented at 0.0044-0.0048 or so;  spending ~26mBTC.  Generating 19-21mBTC after the rental is up....  which is close to the amount the share reports are off by;   and thats also with an extra S3 running that consistently generated 2.2mBTC/day.

The hashrate reporting is almost nominal;  within a few percent; so I know those per-share hashrate calcs are good =)

sorry you pay 26 mBTC for earn 19-21?

yes.

Each time I calculated based on profitability reports from the pool through the day;  the estimates should have been to earn 1-3mBTC after 24 hours.    They obviously kept falling way short.   Even on a days when rental was a lot cheaper than the previous day.

I have a nagging suspicion it has to do with the major difference between pool hashrate % and share reward % that I can see on my zpool wallet page.

I expected to loose out from the start;  so I wasn't disappointed if I did loose coin;  its not that much of a loss to help the pool try and see if there truly is an issue with the calculations somewhere.

I just dont have any way else to explain away the difference between pool hashrate % (on left side where total share amount from each algo is displayed), and the share value of the coins on the right pane where it lists found blocks and credit for them.

Example:

if you check api you will see that site reports actual_last24h values under profitability, better take note on estimate_current and estimate_last24h also, as for % own hashrate towards % pool hashrate, try lowering share diff, the shorter block round is more random % of own shares are as your miner take some time to submit shares and may miss a block, but in next it can submit two shares instead but even if you fix your shares workflow other pool miners and share luck also change. you can use stratum proxy to track your S3 hashrate https://github.com/Stratehm/stratum-proxy

% share rate seems okay for low hash rates. I'm now solo mining the myr-gr algo, and my %share rate is capped at 80%.

[jkminkov]

if you check api you will see that site reports actual_last24h values under profitability, better take note on estimate_current and estimate_last24h also, as for % own hashrate towards % pool hashrate, try lowering share diff, the shorter block round is more random % of own shares are as your miner take some time to submit shares and may miss a block, but in next it can submit two shares instead but even if you fix your shares workflow other pool miners and share luck also change. you can use stratum proxy to track your S3 hashrate https://github.com/Stratehm/stratum-proxy

% share rate seems okay for low hash rates. I'm now solo mining the myr-gr algo, and my %share rate is capped at 80%.

there are 3 coins on myr-gr, you have 80% because you've joined ongoing round on Myriad (myr-gr) highest diff coin where other miner have some shares but have quit before round is finished, I see last found block is 2 days ago.

[AngryDwarf]

if you check api you will see that site reports actual_last24h values under profitability, better take note on estimate_current and estimate_last24h also, as for % own hashrate towards % pool hashrate, try lowering share diff, the shorter block round is more random % of own shares are as your miner take some time to submit shares and may miss a block, but in next it can submit two shares instead but even if you fix your shares workflow other pool miners and share luck also change. you can use stratum proxy to track your S3 hashrate https://github.com/Stratehm/stratum-proxy

% share rate seems okay for low hash rates. I'm now solo mining the myr-gr algo, and my %share rate is capped at 80%.

there are 3 coins on myr-gr, you have 80% because you've joined ongoing round on Myriad (myr-gr) highest diff coin where other miner have some shares but have quit before round is finished, I see last found block is 2 days ago.

But I was adding shares to all 3 coins, and the share rate was exactly 80%. I found a block, but it was orphaned. Also, at this point, I'm not sure if the share contributions are coin specific or shared across the algo. I would thoroughly expect to always have some X11 share hanging around due to DASH contributions, but it doesn't seem to be that way.

EDIT: Definitely seems that contributions are algo wide, someone solves one myr-gr coin and I get my entire share contribution and balance reset to zero. Thats why we sometimes get lucky pending jumps, when we have contributions when someone solves a big coin.

[jkminkov]

http://www.zpool.ca/site/mining

see hashrate on some coins types - it is not evenly distributed, there's some formula to "protect low diff coins" that comes from original yaamp pool config

[jkminkov]

ok, I see what you mean, I found block Rich (myr-gr)   2.004113 RICHX   50.1028%   0.020864   23m ago   Immature (9)

and my miners summary is...

myr-gr   2   80%   19.5 mh/s

and meanwhile as typing another block Saffron (myr-gr)   15.743700 SFR   74.9700%   0.017161   35s ago   Immature (1)

[AngryDwarf]

http://www.zpool.ca/site/mining

see hashrate on some coins types - it is not evenly distributed, there's some formula to "protect low diff coins" that comes from original yaamp pool config

Not sure what it is you are asking me to look at there. If the low diff coin is the most profitable than eventually the luck evens out. Whilst I was mining myr-gr, my income was below norm as all I got was an orphaned block. When someone else solved it later, I got a big payout even though my share contribution had dropped to 30% by that stage. I did have a hash that would have been big enough to solve the low diff coin, but I was on a higher diff coin at the time.

[AngryDwarf]

ok, I see what you mean, I found block Rich (myr-gr)   2.004113 RICHX   50.1028%   0.020864   23m ago   Immature (9)

and my miners summary is...

myr-gr   2   80%   19.5 mh/s

and meanwhile as typing another block Saffron (myr-gr)   15.743700 SFR   74.9700%   0.017161   35s ago   Immature (1)

Yes, that bang on 80% when you have solved a block and you know you are the only mining it. I also thought that when other miners joined in, I was getting my share of 80%. I got just under 30% on that RICHX block.

[jkminkov]

how about most recent Saffron (myr-gr) did you get paid for it?

[AngryDwarf]

how about most recent Saffron (myr-gr) did you get paid for it?

My guess is not, since my share contributions where reset on the RICHX block. Difficult to know for sure as my last 50 earnings can be quickly swamped by fast sha256 coins.

[jkminkov]

see show details on http://www.zpool.ca/?address= check immature under name Saffron (myr-gr) if missing = not paid, otherwise you can divide value by 21(blocksize) to see %

[AngryDwarf]

see show details on http://www.zpool.ca/?address= check immature under name Saffron (myr-gr) if missing = not paid, otherwise you can divide value by 21(blocksize) to see %

Like I say, my last 50 earnings are quickly swamped by fast sha256 coins. It is quite possible another miner jumped in and took 5% just before block was solved whilst you was not looking. I don't see any further hashes from myself.

[jkminkov]

www.zpool.ca
PROP reward system
BTC Payouts
2% Fees (1% while in BETA, ends Dec 1)

can you check if myr-gr on port 5433 and other multiports too, seems pool fee is 20%, not 2%, just added another mining address with all hashrate mine and I get sum of my shares exactly 80%, which means 20% pool fee

if I see balance what I have mined to what is going for exchange, it is even worse 25,03% pool fee 3 Saffron (myr-gr) blocks 3*21 = 63 in my balance there're 47.231100 SFR

[AngryDwarf]

www.zpool.ca
PROP reward system
BTC Payouts
2% Fees (1% while in BETA, ends Dec 1)

can you check if myr-gr on port 5433 and other multiports too, seems pool fee is 20%, not 2%, just added another mining address with all hashrate mine and I get sum of my shares exactly 80%, which means 20% pool fee

Alt coin fees at least seem to be paid along with the transaction. Each transaction has two outputs, the amount paid to you, and the other a fee. I did take a quick look at the Yaamp code and it wouldn't suprise me if there are many holes in it. I saw a bit of code which appeared to reserve 10% of coins, presumably to pay alt coin miners. I do think though that we need an explanation of what is happening here.

[crackfoo]

www.zpool.ca
PROP reward system
BTC Payouts
2% Fees (1% while in BETA, ends Dec 1)

can you check if myr-gr on port 5433 and other multiports too, seems pool fee is 20%, not 2%, just added another mining address with all hashrate mine and I get sum of my shares exactly 80%, which means 20% pool fee

Alt coin fees at least seem to be paid along with the transaction. Each transaction has two outputs, the amount paid to you, and the other a fee. I did take a quick look at the Yaamp code and it wouldn't suprise me if there are many holes in it. I saw a bit of code which appeared to reserve 10% of coins, presumably to pay alt coin miners. I do think though that we need an explanation of what is happening here.

yes the code seems a bit disjointed and hard to follow and tbh, there are parts where I'm not sure what it's doing. I'm going to see if there is a dev that will overhaul the exchange part. The original yiimp dev chooses not to work on the exchange part and that is fine, as they prefer to focus on direct mining.

[jkminkov]

exchange is fine, share distribution is wrong, some formula where instead of =1.0 it is = 0.7497

[Grout]

Oh Zpool. I like you very much but you make it really hard to write software that auto-switch to the most profitable pool (like MinerControl or my own software). Here is an extract from the values returned by your API for the neoscrypt pool :

Code:

2.95757
2.94374
2.94605
2.95738
2.96167
2.96167
2.96167
5375.56269
13.16649
1.68837
2.10255
11.16034
5.42788
5.42788
5.19891
3.63841
3.70073
3.94264
3.94264
2.76667
2.76667

This one abhorrent value (5375 BTC/Gh/day) screws up everyone that switches based on an average. I think it is default behavior for MinerControl (it definitely is for my software) to average the last 2 hours values to make a decision. This single 'error', makes everyone switch to you for the next two hours. Even if you are not the most profitable.

Guess I'll have to work around that and hope it is unintentional.

[crackfoo]

Oh Zpool. I like you very much but you make it really hard to write software that auto-switch to the most profitable pool (like MinerControl or my own software). Here is an extract from the values returned by your API for the neoscrypt pool :

Code:

2.95757
2.94374
2.94605
2.95738
2.96167
2.96167
2.96167
5375.56269
13.16649
1.68837
2.10255
11.16034
5.42788
5.42788
5.19891
3.63841
3.70073
3.94264
3.94264
2.76667
2.76667

This one abhorrent value (5375 BTC/Gh/day) screws up everyone that switches based on an average. I think it is default behavior for MinerControl (it definitely is for my software) to average the last 2 hours values to make a decision. This single 'error', makes everyone switch to you for the next two hours. Even if you are not the most profitable.

Guess I'll have to work around that and hope it is unintentional.

That must have been from UFO. It was diff blocked for a day or two and so when a block was found the chain, well, that would make the diff drop super low to allow it to catchup with blocks and thus making it jump the profitability. I would expect that it would report the same on all pools with UFO in their mix...

[Grout]

Oh Zpool. I like you very much but you make it really hard to write software that auto-switch to the most profitable pool (like MinerControl or my own software). Here is an extract from the values returned by your API for the neoscrypt pool :

Code:

2.95757
2.94374
2.94605
2.95738
2.96167
2.96167
2.96167
5375.56269
13.16649
1.68837
2.10255
11.16034
5.42788
5.42788
5.19891
3.63841
3.70073
3.94264
3.94264
2.76667
2.76667

This one abhorrent value (5375 BTC/Gh/day) screws up everyone that switches based on an average. I think it is default behavior for MinerControl (it definitely is for my software) to average the last 2 hours values to make a decision. This single 'error', makes everyone switch to you for the next two hours. Even if you are not the most profitable.

Guess I'll have to work around that and hope it is unintentional.

That must have been from UFO. It was diff blocked for a day or two and so when a block was found the chain, well, that would make the diff drop super low to allow it to catchup with blocks and thus making it jump the profitability. I would expect that it would report the same on all pools with UFO in their mix...

Well, the only other pool mining UFO I have data on is Hashpower, and they don't show the same fluctuation. In the same timeperiod, their highest value is 5.8. I only have one 'dot' per minute though, so it might have slipped between my API calls.
Anyway, I added a bit of code to ignore these 'anomalies' and it should be OK in the future.

[jkminkov]

exchange is fine, share distribution is wrong, some formula where instead of =1.0 it is = 0.7497

probably here

https://github.com/globalzon/yaamp/blob/master/web/yaamp/core/backend/blocks.php
https://github.com/globalzon/yaamp/blob/master/web/yaamp/core/functions/yaamp.php

those two:

function yaamp_fee($algo)

function take_yaamp_fee($v, $algo)