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

[crackfoo]

THE PHANTOM OF THE ZPOOL


as promised. after all it's plain and simple 30% fee,
the only excuse could be compensating hype of mined shares' stats

is the same seen on BTC addresses?? I haven't been able to tell, but perhaps there is a different code path for non btc exchanging??

[felixbrucker]

THE PHANTOM OF THE ZPOOL



as promised. after all it's plain and simple 30% fee,
the only excuse could be compensating hype of mined shares' stats

im sorry but i dont understand this screen without any description of those numbers and what they mean and in which context they stand. i hope you can clarify

The problem is that Zpool over estimates the exchange values for coins (most of which are actually quite worthless). To calculate how much Zpool's estimates are off do: actual_last24h - (estimate_last24h*1000)

this sadly does not work for algorithms where ttf is high as actual24h is 0 when no block is found (like lbry when pool had 6gh/s)
also it is an average estimate which is useless for current switching, it is only useful to determine if mining a single algo on zpool is profitable

[felixbrucker]

THE PHANTOM OF THE ZPOOL


as promised. after all it's plain and simple 30% fee,
the only excuse could be compensating hype of mined shares' stats

is the same seen on BTC addresses?? I haven't been able to tell, but perhaps there is a different code path for non btc exchanging??

all my payouts noted before where btc, so yes

[aarons6]

so tell me something, is the actual amount you get on par with your hash rate?

[felixbrucker]

so tell me something, is the actual amount you get on par with your hash rate?

using which profitability information for your hashrate?

[c_demian]

Can anyone explain me how I managed to get negative profit from placing an order on nicehash with a price of 1.06 BTC/PH/day to zpool showing average profit estimate 0.00148 mBTC/GHs/day ? (sha256, no errors, no rejects)

You lose on nicehash fee.

You lose on payment tx to NH.

24hr estimates are for the previous 24hr with x hashrate;  not 24 with X plus your rental.


Many ways to loose on a rental.  If t was as easy as you think, machines would be rented 247 by the same people all tihe time earning profit.



I also agree: argon2 is crap.  I don't mine it anymore.

its better to be seller in NH than a buyer, renting.

In NH order details I noticed delta is very big (some 10% - 20%) and is related to "extra rewards" which NH is paying to miners (quote) "due to fast job switching or disconnects". Strange.

[LightZ]

I can`t connect to zpool from miningrigrentals
sha256.mine.zpool.ca:3333

[c_demian]

I can`t connect to zpool from miningrigrentals
sha256.mine.zpool.ca:3333

have you tried setting difficulty like d=8192 in the password field? The rig's description should mention minimal difficulty.

[joblo]

so tell me something, is the actual amount you get on par with your hash rate?

takes another test as well, and slightly more complex.
probably mining on single-coin pool here and the same coin/algo in another pool,
in parallel, 2 ~identical gpu/rigs, time-synced, looong run.
well maybe one rig mining 50/50 would suffice, can't tell for sure.
that may help to see share stats hype here if any.
volunteers ? i don't have time again

That information is already available from the image you posted.

You were monitoring 2 AUR blocks and the block size is 2.5.

.0071 * 2.5 = .01775 vs .01774
.0072 * 2.5 = .018     vs .018

Looks fine to me but I don't think this matters.  As long as the estimate matches the coin amount and price
before exchange, you should get the same value back. Did you check the price and calculate your own estimated
value?

[joblo]

so tell me something, is the actual amount you get on par with your hash rate?

takes another test as well, and slightly more complex.
probably mining on single-coin pool here and the same coin/algo in another pool,
in parallel, 2 ~identical gpu/rigs, time-synced, looong run.
well maybe one rig mining 50/50 would suffice, can't tell for sure.
that may help to see share stats hype here if any.
volunteers ? i don't have time again

That information is already available from the image you posted.

You were monitoring 2 AUR blocks and the block size is 2.5.

.0071 * 2.5 = .01775 vs .01774
.0072 * 2.5 = .018     vs .018

Looks fine to me but I don't think this matters.  As long as the estimate matches the coin amount and price
before exchange, you should get the same value back. Did you check the price and calculate your own estimated
value?

there's nothing wrong with estimates and prices at all, everything checks out,
before exchange and after exchange, shit hits the fan only when it gets cleared

shares hype i meant smth like
pool stats: 0.017743 AUR 0.710% 0.00316
in fact: 0.01242 AUR 0.497% 0.00221
yep rather awkward and impossible if only 1 miner on the pool with no shares left from others,
but i can't think of another excuse for 30% fee.
btw i missed the moment when MYR exchanged to MYR,
can't tell if it's general fee or "exchange" fee (to other coins only)

About the shit hitting the fan when the block is cleared, I just noticed the blocks you highlighted were marked
as cleared but still showed their expected value in AUR, not a reduced value. No error there.

The amount deducted from your AUR pending was equal to the sum of the two blocks you hightlighed, so there is no problem
there either.

Everything in AUR looks correct all the way to the amount deducted on exchange.

The problem is either the exchanged amount (Myriad in your case) is incorrect or it's not being distributed to miners correctly.
That data is not available to users but might be in the logs. If only someone with access to them would check.

Regarding trading fees, you shouldn't pay any because you're paid in an altcoin which are payed out from mined coins.
Only BTC payouts require a trade on an exchange with a fee. The internal trade should also get a favourable price because
there is no bid/ask spread.

[OverP]

Does Someone have a x17 miner that work with rx 480,mine is constantly getting hardware errors

[joblo]

so brothas, in this test i've mined a piece of J (nist5) with payout to J.
pool took exactly 25% off me.

Good work. You just eliminated exchange issues as the problem. You mined J and got paid in J, no exchange required.

Edit: You also eliminated estimates as the problem. The only thing left is the distribution to users.

[crackfoo]

All the fee's in the config are set at 2

https://github.com/tpruvot/yiimp/blob/next/web/serverconfig.sample.php#L18-L20

I do mention on the main page:

You can also use any valid wallet address from any of the coins we mine. This feature has had minimal testing so use at your own risk

But I'm not really sure why I did that, I've had it there since the beginning...

[scyth33]

is MMR and NH blocked from using zpool? Still unable to connect to sha256.mine.zpool.ca:3333

[crackfoo]

is MMR and NH blocked from using zpool? Still unable to connect to sha256.mine.zpool.ca:3333

I've been using NH, but not on SHA... can't see any reason they wouldn't connect...

Whats your mining address start with? just the first 5-6 is fine.

[crackfoo]

is MMR and NH blocked from using zpool? Still unable to connect to sha256.mine.zpool.ca:3333

I've been using NH, but not on SHA... can't see any reason they wouldn't connect...

Whats your mining address start with? just the first 5-6 is fine.

looks like they were banned on that machine. I'll check into this a bit further but plz let me know your address, first 6 char

[scyth33]

is MMR and NH blocked from using zpool? Still unable to connect to sha256.mine.zpool.ca:3333

I've been using NH, but not on SHA... can't see any reason they wouldn't connect...

Whats your mining address start with? just the first 5-6 is fine.

14R8wj

[crackfoo]

is MMR and NH blocked from using zpool? Still unable to connect to sha256.mine.zpool.ca:3333

I've been using NH, but not on SHA... can't see any reason they wouldn't connect...

Whats your mining address start with? just the first 5-6 is fine.

14R8wj

try now

[scyth33]

is MMR and NH blocked from using zpool? Still unable to connect to sha256.mine.zpool.ca:3333

I've been using NH, but not on SHA... can't see any reason they wouldn't connect...

Whats your mining address start with? just the first 5-6 is fine.

14R8wj

try now

yes it is working now! thank you

[joblo]

All the fee's in the config are set at 2

https://github.com/tpruvot/yiimp/blob/next/web/serverconfig.sample.php#L18-L20

I do mention on the main page:

You can also use any valid wallet address from any of the coins we mine. This feature has had minimal testing so use at your own risk

But I'm not really sure why I did that, I've had it there since the beginning...

Mining fee is taken when block is generated: https://github.com/tpruvot/yiimp/blob/next/web/yaamp/core/backend/blocks.php
The exchange fee is applied when market trading is done: https://github.com/tpruvot/yiimp/blob/next/web/yaamp/modules/thread/CronjobController.php

When mining the same coin as payout there is no market activity therefore no exchange fee.

Fees are not the problem. Something is happening when matured, and possibly exchanged, coins are distributed to the users.
The amount deposited does not match the previously listed value. In cases where it is the same coin it should be identical.
The amount listed  in the "last 50" matches the listed percentage of a full block reward.

The process has been traced from the finding of a block to post-exchange and no problems have been found. The problem must be occuring
before the block is listed in the "last 50" or after maturation and exchange when it is being distributed to the users (ie cleared).

If the problem occurred during distribution then it should be obvious that coins went missing. The sum of all users deposits should equal
the block size. If not where did the coins go?

This is starting to look more like an earlier problem where displaed share percentage didn't make sense. If a pool with one miner
was mining one coin it was impossible to get more than around 80% share. To my knowledge this issue was never explained.
It is also suspicious that the error was the same magnitude, ~20%.

Maybe these two issues should be analyzed together, they might be related.