Zpool.ca: Does it take 20-22% fee?

[felixbrucker]

The problem is that whatever "evidence" gets presented gets dismissed by people saying that there were no timestamps or didn't have exactly what they wanted to see.  It is actually really simple for anyone to actually calculate it themselves and yet like me they don't do the calculations and blindly dismiss it as an exchange price difference or something like that.

Even then it comes down to getting someone to find the bug and fix it.  Both Crackfoo and Tpruvot claim no responsibility for the exchanging feature and therefore aren't doing anything to investigate or fix the issue.  Someone will likely have to submit a pull request to the Github and then get lucky enough to actually have it committed.  Then maybe Crackfoo will incorporate it into zpool.   I'm pretty sure I found the problem, but haven't had the time to get my own instance of Yiimp setup to verify for sure that it is the function in question and why it is happening.

All the market prices are a calculation of weighted amounts of 20% of the previous value + 80% of the new value and the function is setup such that if the old amount is 0 or out of scope then it simply returns 80% of the current value.  This would explain exactly why all the values are 20% or more lower than what people are expecting.  I posted a spreadsheet of every coin I mined for a period that I was watching it and in every single case it was lower than the lowest possible market price for the day and yet people still dismissed it as me not giving all the details.

At this point you either accept this missing value from the payouts and mine on Zpool or you don't.  Crackfoo seems at this point to at least acknowledge that there might be some oddities going on, but so far hasn't publicly made any effort to resolve the problem.  There isn't a lot of incentive for him to do it given that we're talking about eliminating a significant portion of his earnings by fixing it.

I still think that people would be more than willing to pay an exchange fee if they knew what the fee was supposed to be and have it applied consistently.  I'll continue to try and get things working so I can try and prove out and fix the bug, but its going to likely take me some time.

the problem i (and very likely others as well) have is the following: when offered help in finding the "bug" crackfoo didnt want to share even the the slightest logs to determine where exactly the coins get "lost"

[1715031461]

1715031461

[1715031461]

1715031461

[1715031461]

1715031461

[1715031461]

1715031461

[philipma1957]

and I still see 50% higher return here then nicehash.

And I look at mining here as mining btc

and  no sha 256 gear in the world  comes close to mining here.

and every complaint I see  is based on cherry picked   sell  of coins mined at an exchange..


Still I  know that even with all of the above  true.

 it only means  I am better

mining on zpool  then nicehash
mining on zpool then mining with s-9's

I have   been really busy  and have simply not set up a tester pair of rigs.

I also  never switch  as switching  software is really  not a good thing.  it causes lot of issues such as lost shares and flattening of coins prices.  

also  you are always chasing the hot coin along with every else using the software  so the switch to the hot coin is not you but everyone else  and this will kill price.

BTW  i do not switch on nicehash.  

I mine 1 coin at nicehash using 5 1080 ti's
I mine 2 coins at zpool    using 7  1080 ti's

I should earn  at a  7 to 5 ratio    
I earn at a 9 to 5 ratio  

I earn  say .18  at  zpool each month  vs .11 at nicehash

and I earn .14 each week at btc pools  directly.

[joshuaj]

I stand corrected.   I did my own calculations and there is most DEFINITELY a 20% cut being taken.

My evidence

Feel free to take a look at all the work and check it for errors:
https://docs.google.com/spreadsheets/d/18G3-tVapwWzVAp83SExJpZlLAmahLDoNwQBIETDPeeU/edit?usp=sharing


Image of wallet payouts:
https://i.imgur.com/zrvXM9A.png

As you can see in every single case EXCEPT SIGT I was paid no more than 94% of the LOWEST market price for the last 24 hours.  



So as you can see even if all coins were sold at LOWEST market value for the last 24 hours I was paid on average 84% of that amount.  Every coin has moved to the exchange and cleared and is sitting in my unpaid value.  With the exception of SIGT which had a price range of over 300% change throughout the day the value of every coin sold was LESS than the lowest market price.

There are screenshots of every exchange that I used for pricing data showing that it is for the last 24 hours and it includes my system clock in the lower right showing both date and time I checked the data.

As I said mine on Zpool if you want, but just be aware of the truth in payouts.   Either Crackfoo's exchange script dumps well below the lowest market price for the day, we pay a HUGE exchange fee, or there is a cut being taken above the 2-2.5% fees advertised.   I have nothing to gain by presenting the information.  My goal is only to inform.

Thanks for your valuable detailed information. I did not really realize the difference previously, it seems like zpool had very bad coin exchange rate.

[Jaerin]

and I still see 50% higher return here then nicehash.

And I look at mining here as mining btc

and  no sha 256 gear in the world  comes close to mining here.

and every complaint I see  is based on cherry picked   sell  of coins mined at an exchange..


Still I  know that even with all of the above  true.

 it only means  I am better

mining on zpool  then nicehash
mining on zpool then mining with s-9's

I have   been really busy  and have simply not set up a tester pair of rigs.

I also  never switch  as switching  software is really  not a good thing.  it causes lot of issues such as lost shares and flattening of coins prices.  

also  you are always chasing the hot coin along with every else using the software  so the switch to the hot coin is not you but everyone else  and this will kill price.

BTW  i do not switch on nicehash.  

I mine 1 coin at nicehash using 5 1080 ti's
I mine 2 coins at zpool    using 7  1080 ti's

I should earn  at a  7 to 5 ratio    
I earn at a 9 to 5 ratio  

I earn  say .18  at  zpool each month  vs .11 at nicehash

and I earn .14 each week at btc pools  directly.

It isn't cherry picked data though.   If you look earlier that was every coin I mined for a few hour period.  Every single coin was well below the lowest market price of the day.

That's the other issue, yes, zpool pays better than Nicehash, but there are several reasons for that.   Nicehash you're not mining even coins on an algorithm, you are selling your hashrate to whomever wants to buy and decide what you mine.  If no one wants to buy your hash then you get paid whatever someone will pay for it.  Meaning the price of the coin is irrelevant, it is all up to the demand of Nicehash services.  Just because zpool is the better paying pool doesn't mean that there isn't a problem with what is getting paid out.

We just need to find the actual evidence showing the actual bug, or don't mine there and sell the coins yourself.  It's really not that hard to dump them to the exchange and sell them for whatever they happened to be worth at the time.  It will still likely be more than if you mined at zpool as long as you're willing to take those steps to sell them off.  Exchange accounts are typically free so its not even really a barrier.

[philipma1957]

and I still see 50% higher return here then nicehash.

And I look at mining here as mining btc

and  no sha 256 gear in the world  comes close to mining here.

and every complaint I see  is based on cherry picked   sell  of coins mined at an exchange..


Still I  know that even with all of the above  true.

 it only means  I am better

mining on zpool  then nicehash
mining on zpool then mining with s-9's

I have   been really busy  and have simply not set up a tester pair of rigs.

I also  never switch  as switching  software is really  not a good thing.  it causes lot of issues such as lost shares and flattening of coins prices.  

also  you are always chasing the hot coin along with every else using the software  so the switch to the hot coin is not you but everyone else  and this will kill price.

BTW  i do not switch on nicehash.  

I mine 1 coin at nicehash using 5 1080 ti's
I mine 2 coins at zpool    using 7  1080 ti's

I should earn  at a  7 to 5 ratio    
I earn at a 9 to 5 ratio  

I earn  say .18  at  zpool each month  vs .11 at nicehash

and I earn .14 each week at btc pools  directly.

It isn't cherry picked data though.   If you look earlier that was every coin I mined for a few hour period.  Every single coin was well below the lowest market price of the day.

That's the other issue, yes, zpool pays better than Nicehash, but there are several reasons for that.   Nicehash you're not mining even coins on an algorithm, you are selling your hashrate to whomever wants to buy and decide what you mine.  If no one wants to buy your hash then you get paid whatever someone will pay for it.  Meaning the price of the coin is irrelevant, it is all up to the demand of Nicehash services.  Just because zpool is the better paying pool doesn't mean that there isn't a problem with what is getting paid out.

We just need to find the actual evidence showing the actual bug, or don't mine there and sell the coins yourself.  It's really not that hard to dump them to the exchange and sell them for whatever they happened to be worth at the time.  It will still likely be more than if you mined at zpool as long as you're willing to take those steps to sell them off.  Exchange accounts are typically free so its not even really a barrier.

The few hour test is the problem.  It greatly increases the chances of getting fucked because you mined for only two hours.  Then switch .  There is a huge chance you did not hit a block right before you leave.


This causes you to lose shares.

Here is what I mean.  Mine 2 hours hit 1 block. Chances are you hit not at the last minute so many pools drop your shares say for twenty or thirty minutes.  You also don't get proper info on the exact amount of shares since you left early.

If you mine just skein for 200 hours and hit 100 blocks then switch. You lose shares  say for twenty or thirty minutes.  But you keep shares for 100 blocks.

So. A two hour test make a block and lose twenty minutes worth of shares on the next block made.

Vs a 200 hour test  with 100 blocks made then switch and lose 20 or 30 minutes

The 2 hour test will be off as 20 minutes is a huge portion to
Lose.  The 200 hour test. Will be much more accurate as 20 minutes of hash lost is not much compared to 200 hours.

I would ask you to do a 200 hour test with skein on zpool no switching. And at the same time do it for yimp pool.

If you think 200 hours is too long. Do a 50 hour test.  Two rigs zero switching.  Same coin. Convert all coin to btc

Do the test again convert all coin to btc
Do it again convert all coin to btc
Do it again convert all coin to btc

That would be four 50 hour tests one coin zero switching .

If your 20% claim is true it will show as a 20 percent difference is huge.

Crack foo dismisses a lot of claims he did with me when one btc addy I used worked and one did not .

Told me it was on my end. It took a long time to get that address to work.  Yet others worked easy.

But I think your testing method is not good due to shares not being credited with short test methods 2 hours.

[Jaerin]

You don't seem to understand how the prices and things are calculated.

I was not looking at the total payout over time and saying man that seems low.  I was looking at every reported coin that was mined in the earnings section and comparing the paid out value of those coins to the market prices of the day that the coins were exchanged and every single one was below the lowest market value by 20% or more.  How does one sell coins below the lowest market value for a day?

I've mined on Zpool for a couple of months.   You can do these same calculations yourself and see the same thing.  When you mine a coin it shows up in your earnings as X coins mined, share %, how much mBTC those coins are worth.  That price of the mBTC will fluctuate periodically as the coin moves from Immature, Exchange, and Cleared.  At any time during that period you can take the number of coins, multiply it by the current market price and you will see that the mBTC listed is 20%+ less than the market price.  Then when the coin actually is cleared you will see that is the actual mBTC value that is moved from unconfirmed to unpaid in your total amount.

I posted screenshots every single market that I gathered the prices from to prove that I wasn't just misreading the prices and making stuff up.   My system clock is in the lower right corner of all those screenshots to prove the date and time that those prices were checked.  I have nothing to gain by spending hours of my time try to prove this to people other than to try and get it fixed so that I can feel comfortable mining on zpool again.

Try it yourself and you will see exactly what I'm talking about.  Most coins only have one major exchange that they trade on so it is pretty easy to determine where the price is coming from.  That's what led me to looking at the code of Yiimp and seeing this evidence in the code.  I'm still trying to get a fully working Yiimp pool setup just to test what prices are coming from the exchange, but this appears to be the problem.


The relevant function that I believe is causing the issues is as follows:

In web\yaamp\core\backend\markets.php on line 203

Code:

function AverageIncrement($value1, $value2)
{
	$percent = 80;
	$value = ($value1*(100-$percent) + $value2*$percent) / 100;

	return $value;
}

This function is used for pretty much every price lookup from the markets.  The purpose of this function is to create a weighted value based upon 20% of value1 and 80% of value2.  The reason for doing it is to create a trailing average for price moves.  As an example in the price look up for any of the exchanges.

web\yaamp\core\exchange\bittrex.php on line 61-63

Code:

	$price2 = ($m->Bid + $m->Ask)/2;
	$market->price2 = AverageIncrement($market->price2, $price2);
	$market->price = AverageIncrement($market->price, $m->Bid);

The purpose of this code is to first get the average of the Bid and Ask and put it in price2.
Next it sets the price2 value to the weighted value of the previous price2 and the current price2.  This would be a 20% weight of the old price + 80% value of the new price.
Finally it sets the price value to the weighted value of the previous price and the current bid.  This would be a 20% weight of the old bid + 80% value of the new bid.

On paper this seems reasonable because if the price fluctuates by a significant margin it will trail that value and essentially smooth the movement out.  

This is significant because if you look at the AverageIncrement function and consider that if the previous price being passed in value1 does not exist then the function returns 80% of the current price2 or Bid.  So I think what might be happening is somehow the object is falling out of scope or some other issue that is causing that value1 to get a 0 amount and therefore the values coming out are 80% of the value they should be.

As a workaround until it can be determined if the values are being passed incorrectly or falling out of scope a line to check if value1 is 0 and if it is return the value2 should work around the issue.  I'm going to likely try and setup a Yiimp instance on a test VM and see if I can get values out of it to determine for sure if this is the problem.

I'll let you know what I find.  Crackfoo if you want to perhaps add some debug logging like the following it may be quicker for you to see:

Code:

function AverageIncrement($value1, $value2)
{
	$percent = 80;
	$value = ($value1*(100-$percent) + $value2*$percent) / 100;

        debuglog("AverageIncrement: $value1, $value2");

	return $value;
}

Or report it to Tpruvot and see if he can look at it.  I'm pretty sure this is what is causing the issues.

[joblo]

I don't agree with your analysis.

A zero value in AverageIncrement would most likely occur on a failed exchange query and only assuming
there are no error checks. In such cases a zero bid price is possible.

This would cause a 20% drop in the value of $market->price in the current sample.

In the next sample we would adjust based on a new bid price. If a second failure occurs $msrket->price
would become 80% of 80%, or 64%. Each successive failure would reduce the value more.

If the following samples returned a valid bid price the value of $market->price would gradually correct itself.

There is no way to maintain a consistent 20% penalty.

Did you do a test as I suggested?

[Jaerin]

I don't agree with your analysis.

A zero value in AverageIncrement would most likely occur on a failed exchange query and only assuming
there are no error checks. In such cases a zero bid price is possible.

This would cause a 20% drop in the value of $market->price in the current sample.

In the next sample we would adjust based on a new bid price. If a second failure occurs $msrket->price
would become 80% of 80%, or 64%. Each successive failure would reduce the value more.

If the following samples returned a valid bid price the value of $market->price would gradually correct itself.

There is no way to maintain a consistent 20% penalty.

Did you do a test as I suggested?

Actually the value won't keep dropping.  It will just always be 80% of the current bid.  The function grabs 20% of the previous value and 80% of the current.  I'm saying that the 20% is returning 0 because the market object is falling out of scope and therefore you only get 80% of the current bid.

As for your test that isn't much of a valid test either because the conversion of coins to BTC for Yiimp won't necessarily be at the same time or the same prices as when Zpool does it.  It could be easily explained that the test cherry picked the prices that were sold at and not a valid test.

As for the loss of shares that actually doesn't happen on Zpool unless the algo never finds a block again.  Even if you only mine for 1 minute on an algorithm you will get your tiny share the next time a block is found.  You don't need to wait until a block if found to make sure your shares are recorded.  The shares are recorded in the database and paid out when the next block is found.


It would be simple for Crackfoo to determine what the problem is, but it would require him to look at the logs and see what prices it is recording for the pairs and compare them to the exchange.   That's why I need to get a Yiimp instance working so that I can see exactly what it is doing.   The code definitely looks like it could be a problem if the existing market price is not getting carried forward.

This would be a simple fix as well:

Code:

function AverageIncrement($value1, $value2)
{
        if $value == 0 then return $value2;
	$percent = 80;
	$value = ($value1*(100-$percent) + $value2*$percent) / 100;

	return $value;
}

[joblo]

You're just assuming that $market forgets its current value when updating. That would result in a consistent
80% value but this would only ocurr if $market is a local variable. A global wouldn't lose its value between
iterations of the same function. And "out of scope" just means there are two copies of the same variable name
in a different scope. The reference in any single function will allways be in scope.

I think you've latched on to this 20% code and just assumed it is the source of the problem.

You also overcomplicated my test. You just need to follow one block on zpool from creation to credit to your balance.
All of the raw data is there, share%, coin amount, BTC value. The BTC value can be expected to fluctuate with
exchange price. The last BTC value displayed before exchange should be very close to the actual exchanged value,
Simply confirm that the expected amount was credited to your balance.

[guytechie]

So does this mean neither Crackfoo or Tpruvot are going to lift a finger to assist you in this?

[Jaerin]

You're just assuming that $market forgets its current value when updating. That would result in a consistent
80% value but this would only ocurr if $market is a local variable. A global wouldn't lose its value between
iterations of the same function. And "out of scope" just means there are two copies of the same variable name
in a different scope. The reference in any single function will allways be in scope.

I think you've latched on to this 20% code and just assumed it is the source of the problem.

You also overcomplicated my test. You just need to follow one block on zpool from creation to credit to your balance.
All of the raw data is there, share%, coin amount, BTC value. The BTC value can be expected to fluctuate with
exchange price. The last BTC value displayed before exchange should be very close to the actual exchanged value,
Simply confirm that the expected amount was credited to your balance.

And you're ignoring that is exactly what I did.  If you look at my spreadsheet you see where I show in screenshots every market price that compares to the coins that I mined and what prices were given on the pool.  The unpaid amount was the same as what all the coins were supposed to credit to me that were all well below the lowest market price of the day.  Do the calculations and you will see the same thing.  I've already done the tests, if you don't believe the results then do them yourself and you will see exactly what I'm talking about.

As for the code that's exactly why I haven't submitted a bug report and I said as much.   I want to get the pool setup and see for myself if that object is 0, but it would explain the results that we're seeing.  I feel like I'm being very reasonable with my report and evidence and yet again all I'm met with is excuses and more doubts of the tests and evidence.  I didn't want to believe that was the case either, but it does seem to be true. 

[joblo]

You're just assuming that $market forgets its current value when updating. That would result in a consistent
80% value but this would only ocurr if $market is a local variable. A global wouldn't lose its value between
iterations of the same function. And "out of scope" just means there are two copies of the same variable name
in a different scope. The reference in any single function will allways be in scope.

I think you've latched on to this 20% code and just assumed it is the source of the problem.

You also overcomplicated my test. You just need to follow one block on zpool from creation to credit to your balance.
All of the raw data is there, share%, coin amount, BTC value. The BTC value can be expected to fluctuate with
exchange price. The last BTC value displayed before exchange should be very close to the actual exchanged value,
Simply confirm that the expected amount was credited to your balance.

And you're ignoring that is exactly what I did.  If you look at my spreadsheet you see where I show in screenshots every market price that compares to the coins that I mined and what prices were given on the pool.  The unpaid amount was the same as what all the coins were supposed to credit to me that were all well below the lowest market price of the day.  Do the calculations and you will see the same thing.  I've already done the tests, if you don't believe the results then do them yourself and you will see exactly what I'm talking about.

As for the code that's exactly why I haven't submitted a bug report and I said as much.   I want to get the pool setup and see for myself if that object is 0, but it would explain the results that we're seeing.  I feel like I'm being very reasonable with my report and evidence and yet again all I'm met with is excuses and more doubts of the tests and evidence.  I didn't want to believe that was the case either, but it does seem to be true. 

I can see that you listed a lot of numbers but I don't know where they came from or what they mean. In particular how did
you determine the expected value? Maybe if you walked through one example it might help understand.

The problem you seem to be seeing is exchange related. If you review the previous reports in the old locked thread you
will see a 20% loss even when the payout coin is the same as mined, ie no exchange. Either there are 2 seperate problems,
both resulting in losing 20%, or you haven't yet zeroed in on the original problem.

I'm not disagreeing that you saw a problem just disagreeing with your analysis of it. Seeing an obvious reference to 20% in
the code is certainly suspicious and deserves to be pursued. In my analysis of that code I can't see how it
results in being short changed at the exchange. That code only is used to display estimates for the pool, it has nothing to
do with the actual trade on the exchnage.

[Jaerin]

Here you can see the coins that I mined in the last 60 mins or so.  I originally recorded an hour long video of it, but for some reason Shadowplay decided to fast forward a chunk of the audio, but not the video and therefore they got out of sync.  I will try and explain where all the numbers come from:

Here are the earnings on my wallet:


In the Amount column you can see exactly how many of each coin I mined for that particular block.  You can also see the mBTC payout value of those said coins.

If you look at the Wallet payout information you will see that in total it is expected to payout 0.00000549 BTC.  This matches the value of the sum of all the coins in BTC value in the following spreadsheet Cell D17.  Then looking on coinmarketcap.com I took the current BID value for Auroracoin which is traded on Bittrex and Topaz which is traded on Novaexchange.   Column F shows the current BID price of the coins on the respective exchanges.   Column G is the proceeds of that exchange.  In both cases the exchange fees for trading are less than 1%.  The Exchange proceeds in Column G is showing how much BTC each set of coins should produce.   Column H is the percentage of value the zpool is giving compared to what is generated on the Exchange.  As you can see in every case the value is 85% of the value that Zpool is paying.  This is the way that I've calculated it every time and you can too.

At this point it appears that perhaps Crackfoo has adjusted something because in my previous example it was 80% in almost every case.  So that is where all the numbers came from and how I was deriving the value of the coins compared to what Zpool was paying.  As of right now Zpool appears to be paying 85% of the current bid value of the coins.  You can see the price per coin paid out in the E column vs the F column.





Link to the spreadsheet to verify all formulas:
https://docs.google.com/spreadsheets/d/1pJud4B3tZD5Y587GJhpHy655KeakClbcNw8U2JI6YnY

[joblo]

It gets confusing with all the superfluous data like hashtap. Like I said before it's better to track one block from
start to finish. There is less noise to distract the skeptics.

I did that with the Aurora blocks (Topaz is just a rounding error) and I now see clearly. At no time in the last week
has AUR dropped below .017 mBTC yet you only got .014.

It looks to me that the problem got moved. Previously everthing was correct until the block was cleared and
added to the balance. This could result in a very obvious drop in total unpaid with every balance increase.

Now the 20% is already lost when the block is first posted. This avoids the visible manifestation in the graph
when the 30% is taken away. I'd suspect an attenpt to cover up but now it's even more obvious because all one
has to do is audit the amount and value against the exchange rate and see it's 20% below market. Unless a coin
has more than 20% volatility it should be obvious.

That was excellent work but it took me a while to understand it.

[Storx]

It gets confusing with all the superfluous data like hashtap. Like I said before it's better to track one block from
start to finish. There is less noise to distract the skeptics.

I did that with the Aurora blocks (Topaz is just a rounding error) and I now see clearly. At no time in the last week
has AUR dropped below .017 mBTC yet you only got .014.

It looks to me that the problem got moved. Previously everthing was correct until the block was cleared and
added to the balance. This could result in a very obvious drop in total unpaid with every balance increase.

Now the 20% is already lost when the block is first posted. This avoids the visible manifestation in the graph
when the 30% is taken away. I'd suspect an attenpt to cover up but now it's even more obvious because all one
has to do is audit the amount and value against the exchange rate and see it's 20% below market. Unless a coin
has more than 20% volatility it should be obvious.

That was excellent work but it took me a while to understand it.

This is the exact reason i gave up mining zpool, i tried to use it for skunkhash/SIGT on the 25th of July, because Suprnova SIGT went down, so i moved all my rigs over to zpool to stay mining SIGT, my amount of hashpower i currently have mined 88% of block i helped with and i was only payed out 31mBTC for that which pissed me off.. so i found another pool Yiimp and very quickly switched tell suprnova came back up.. i gave Zpool another chance and it screwed me harder.. because those first few days SIGT payouts were extremely high and i got robbed....

the 25th of July, the LOWEST the coin hit was 2206 for the entire period, but exchanged time took place around the 4k range, because we had so little hashpower to find the blocks back then.. so took a good minute for the next block...



First of all, it says i mined 88.206% of the block, i didnt catch this at first, i was just disgusted with the payout... but after switching on pure earnings being low to begin with, because i use Awesome miner and it tracks your stats and the numbers were just not adding up, based on the hashpower/diff value/ and period of time i was mining.. but the coins it gave me credit for doesnt even match the % it says i hashed...

So that block i was payed out 31.83mBTC for my work, but if you take the LOWEST 24hr level for that entire day and do the math that number would be 43.12mBTC, but in reality the earned blocked occured when SIGT was around the 4k range.. so it should have been around 78.20mBTC.... and those are all numbers going off the 1955 number....

If you go by the share % it reports, i would be closer to 2205.15 coins... so the difference is actually even larger if you go by the %, that would put the value around 88.20mBTC

So off one block i was payed out 31.83mBTC on a block that should have payed me closer to 80ish mBTC...

But wait, there is more....

After all of this i compared the numbers of my share rate on Suprnova to the Zpool numbers, i mined 5ish blocks on zpool before i switched...If you take the start time logged in Awesome miner when i started mining on zpool tell the last time stamp when i stopped the miner, my day average on zpool was 13,807 coin/day based on the coins credited on the blocks i did mined on via the website... the coins/day rate on suprnova before and after were much higher.. before going to zpool i was averaging a rate of 16,301, but after switching off zpool and going to Yiimp tell suprnova came back online, i was averaging 15,883/day

So something is just not adding up, either the website is reporting wrong info or something is messing up in the code, but even if the website is reporting wrong numbers, your payouts are matching those exchanged website postings.. so somehow the numbers are just getting messed with, dropped off, or not adding up correctly to pay us out correctly

[Storx]

I started this forum post months ago, because when i first started mining on Zpool the numbers were just not adding up to the "24hr Actual Earnings" posted on the pool site when i was mining skein days on without any switching back then.. i asked and many people to including Jaerin talked me out of the missing earnings based on ideas and such that could be the reason i was seeing such differences..  so i stayed on the pool and mined for a good while as others dropped in and kept reporting the same things i had brought up previously, but everytime people defended the reason the earnings were not matching/adding up... or those people's post were deleted nearly instantly off the zpool post.. so i started branching out testing the waters on other pools while i continued to mainly mine on zpool, because honestly the btc auto exchange was huge benefit that kept me coming back, because i was still learning about the exchanges and such.. but months later Jaerin who of all people defended all the times i questioned the earnings months ago started bringing it up, i was like wow what the heck is going on......

[ma7555]

has this been sorted? any news about this exact missing coins problem?

[mjmeans]

Code:

function AverageIncrement($value1, $value2)
{
	$percent = 80;
	$value = ($value1*(100-$percent) + $value2*$percent) / 100;

        debuglog("AverageIncrement: $value1, $value2");

	return $value;
}

Or report it to Tpruvot and see if he can look at it.  I'm pretty sure this is what is causing the issues.

Did you ever set up a VM to test this? If there is a race condition that is affecting this function it may only happen under heavy server load or heavy internet traffic. So you will want to run a stress test on the VM while this is running to see if the problem occurs only under stress. Also pull the network connection. See if a dropped connection affects it.


But better than all that testing is this: If either value has 0, then return the other value. So if the old value is 0 then there is nothing to average, so take the new value. If the new value is 0 then there was a server error or a race condition and no new data has actually been received, so keep the old value.

Code:

function AverageIncrement($value1, $value2)
{
	if ($value1 == 0) return $value2;
        if ($value2 == 0) return $value1;
	$percent = 80;
	$value = ($value1*(100-$percent) + $value2*$percent) / 100;
	return $value;
}

That all being said, this is an extremely poor averaging function. Since it seems that things sit in the exchange state for 4-6 hours, a WMA over the previous 6 hours of samples with samples collected every 5 minutes would be a much better average. And that collected data could allow a much better prediction of future value by projecting upper and lower trend for the next 5 minute sample. The mBTC column for predicted value would then show x.xxxxx(+/- y.yyyyy). This predicted value should only be shown when the state is immature or exchange, since we don't know the final exchange rate until it's cleared. But when cleared the exchange transaction should be analyzed and the actual rate of exchange reported and paid. Add to keep it open and transparent, so clicking on any of the lines in the payout list should display a page showing the data and the calculation. That way everyone knows that it is working the way it should.

[mjmeans]

You can easily give the data you collected and turn it over the FBI with a complaint (even if he and his site is in Canada or another country). 300K in USD is a serious crime and they will investigate and coordinate with Canada and other countries to gather additional evidence. But first there has to be a person filing a complaint that has legal "standing".

[sunk818]

Wow, what corruption if zpool's 20%-15% deceitful take rate is true!

They do take quite a lot, but what else pool I can use if I want auto exchange to BTC?
I am using miningpoolhub sometimes, but it has less coins to mine.
I don't want to sell myself, it is simply too much hassle.

I'm just starting out so I've dabbled in multipool and zpool. What about multipool.us? They just give you the coins you mined. I think having the pool just give you the coins makes it easier to audit based on block reward, accepted shares, etc. Pool is not involved in converting or exchanging coins in any way. You get a split of the solved block and that's it.

I just signed up for Bittrex and noticed they have many altcoin wallets. I also noticed they have an autosell to BTC feature. You sweep daily (or based on your threshold) from multipool.us to Bittrex. Then Bittrex autosells to BTC. You can then audit that the exchange gave you the correct price.

Seems easier to audit the pool and exchange rates (sell altcoins to BTC) when the process is separated.