Topic: Zpool.ca: Does it take 20-22% fee? - page 3. (Read 15059 times)

I plee the 5th. But I'm in canada so that doesn't exsit.

Don't worry I wont say who you are or anything.

Just wanted to know if you were real and you are.

Now you’ve deleted your posts wolf, after assuming you know my life and personality?

It may be that some people are lying, but it also may be that ignorance caused by that the lack of complete transparency and auditability feeds suspicion. You can't expect people to examine the source code to know how it works especially when this is (or should be) a simple accounting matter for your system to report.

Would it be possible to add more detail to the explorer for an exchanged coin transaction through it's entire life from mined coin to final coin, http://www.zpool.ca/explorer/ORB?height=2271808? i.e. the detail page not only shows the block mined (as it does now), but also the total mined coin in the block, and your share. AND most importantly the details about how the mined coin was exchanged: your coin was sent to exchange "x", the total coins exchanged in that exchange transaction was "y", and your share of those exchanged coins is "z", and the exchange fee. Basically I want to be able to see the full accounting from start to end: "A" coins mined - "B" fees (detail of each fee including pool fee) = "C" net coins mined => "C" net coins mined * "D" exchange rate - "E" fee (detail of each fee including exchange fee) = "F" final exchanged coin. The sum of all "F" values should exactly equal the account balance. If it doesn't, then more detail need to be added so that anyone can see the full calculation.

Whether this information can be attained through some other means is not relevant. The pool has all this information and it breeds suspicion if the information is not easy to see. If you can make these details easily available, and there is no errors, then you would alleviate 99% of everyone's suspicion.

I'm not sure where you get off saying this but you can clearly see each time a BCC block is found it's added to your accounts. 6 blocks in the past 24h and all credited.

https://pasteboard.co/GNFoO5N.png

Sorry for whoever's address this is

http://zpool.ca/?address=1C5qZGgoshJoCwEZkRVony1DTEmbR7Vgk2

To say I'm keeping them all to myself it simple an outright lie.

maybe the pool really took the 20% fee, but in many experiment it show zpool can get more income than other pool.
so if get more income, why not

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


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.

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

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.


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.

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

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

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

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.

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

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.

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. 

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

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.

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:

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?

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


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



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:


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