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

[MeteoImpact]

snip

Just set this pool up on my switcher today and was noticing that payouts seemed oddly a bit lower than expected; perhaps this share distribution thing is the culprit. Right now I've set my software to lower its estimates for the pool, but I'll be keeping an eye on this issue.

EDIT: Just looking at that snippet compared to YIIMP's code, it does seem like the hashrate distribution might indeed be set to function under the assumption that there is a 20% pool fee, rather than the intended 2%. In the original code from YIIMP, $percent is set to 1, which is what their fee is.

[AngryDwarf]

https://github.com/tpruvot/yiimp/blob/yiimp/web/yaamp/core/backend/sell.php

Following code shows there is a coin reserve function in place. The more a single coin is mined, the greater that is held in reserve, before it will fallback again. I'm not sure if this has any effect on users earnings over time. But it could be that pointing large amounts of rented hash is detrimental the hash renter, and beneficial to the consistent miners. I cannot be sure, more analysis needed.

Code:

function sellCoinToExchange($coin)
{
	if($coin->dontsell) return;
	$remote = new Bitcoin($coin->rpcuser, $coin->rpcpasswd, $coin->rpchost, $coin->rpcport);
	$info = $remote->getinfo();
	if(!$info || !$info['balance']) return false;
	if(!empty($coin->symbol2))
	{
		$coin2 = getdbosql('db_coins', "symbol='$coin->symbol2'");
		if(!$coin2) return;
		$amount = $info['balance'] - $info['paytxfee'];
		$amount *= 0.9;
//		debuglog("sending $amount $coin->symbol to main wallet");
		$tx = $remote->sendtoaddress($coin2->master_wallet, $amount);
//		if(!$tx) debuglog($remote->error);
		return;
	}
	$market = getBestMarket($coin);
	if(!$market) return;
	if(!$coin->sellonbid && $market->lastsent != null && $market->lastsent > $market->lasttraded)
	{
//		debuglog("*** not sending $coin->name to $market->name. last tx is late ***");
		return;
	}
	$deposit_address = $market->deposit_address;
	$marketname = $market->name;
	if(empty($deposit_address)) return false;
	$reserved1 = dboscalar("select sum(balance) from accounts where coinid=$coin->id");
	$reserved2 = dboscalar("select sum(amount*price) from earnings
		where status!=2 and userid in (select id from accounts where coinid=$coin->id)");
	$reserved = ($reserved1 + $reserved2) * 10;
	$amount = $info['balance'] - $info['paytxfee'] - $reserved;

[AngryDwarf]

snip

Just set this pool up on my switcher today and was noticing that payouts seemed oddly a bit lower than expected; perhaps this share distribution thing is the culprit. Right now I've set my software to lower its estimates for the pool, but I'll be keeping an eye on this issue.

EDIT: Just looking at that snippet compared to YIIMP's code, it does seem like the hashrate distribution might indeed be set to function under the assumption that there is a 20% pool fee, rather than the intended 2%. In the original code from YIIMP, $percent is set to 1, which is what their fee is.

It seems like a very strange way of calculating it to me, and hopefully just a statistical reporting error. It might explain though why my reported hash rate is generally lower than my miner output. However, when solo mining an unpopular algo, I think the formula adds up to 100%, not 80%. So there must be another strange calculation reporting the percentage somewhere.
Profitability has been lower for me over the last few hours. Be careful how you get your profitability stats. The ones on the main algo page are a different kettle of fish to those under the pool page.

[AngryDwarf]

by request, for coins that have queued miner payments (coins that show red in the stats), we've added how much we're behind so you can have a better decision to continue mining for that altcoin or switch back to BTC.

Thanks, do we have to wait for the next block to be solved before the payouts kick in? I've still got pending payments in DASH and SYS.

[crackfoo]

by request, for coins that have queued miner payments (coins that show red in the stats), we've added how much we're behind so you can have a better decision to continue mining for that altcoin or switch back to BTC.

Thanks, do we have to wait for the next block to be solved before the payouts kick in? I've still got pending payments in DASH and SYS.

Yes, for PoW coins, payouts are from found blocks.

[crackfoo]

I've seen that some people would like less frequent payouts, to reduce the amount of tx's in wallets.

how often would you like to get paid and/or how much would you prefer the minim to be?

Cheers!

[jkminkov]

once a day, same minimum

[dudu2000]

Hello Crackfoo

LTC payments?  

[AngryDwarf]

I've seen that some people would like less frequent payouts, to reduce the amount of tx's in wallets.

how often would you like to get paid and/or how much would you prefer the minim to be?

Cheers!

It's quite a double edged sword of a question. If I am mining BTC it takes me best part of a day to hit 1mBTC anyway, so a daily payment wouldn't make much difference. Luckily, I have a few big chunks of BTC so I can combine these small transactions into bigger chunks using coin control and sending as a free transaction when possible (even if it may take a week to confirm).
If am mining DGB to send to the exchange for DASH or LTC (where the pool just does not mine enough to support), or other currencies, the faster payout schedule minimises price movement risk (and of course, DGB can be easily combined using coin control and sent as free transactions easily).
So maybe a password parameter switch? Keep it short for us ccminers with 127 length limit!

Don't know if it is just me, but miner hash rate looks better recently. Thanks.

[JaredKaragen]

@crackfoo have you considered adding etherium?   It's price has done some huge leaps and bounds today....

I've seen that some people would like less frequent payouts, to reduce the amount of tx's in wallets.

how often would you like to get paid and/or how much would you prefer the minim to be?

Cheers!

maybe a password flag for maximum payout frequency per day I.E>   PO=3 (3 payouts/day), or PO=0.5(one payout every 2 days)  if no flag set;  keep current payout schedule.

Trying to get my head around this bit of code 

https://github.com/tpruvot/yiimp/blob/yiimp/web/yaamp/core/backend/stats.php

EDIT: not sure this really explains some of the issues we are seeing, but it is an example of an arbitary use of that magic missing 20%.

A bit further up in the code, seems someone finds it strange too (strange calculation commented out):

Code:

		$pool_rate = yaamp_pool_rate($algo);
		$stats->hashrate = $pool_rate;	//round(($stats->hashrate*(100-$percent) + $pool_rate*$percent) / 100);
		$pool_rate_bad = yaamp_pool_rate_bad($algo);
		$stats->hashrate_bad = $pool_rate_bad;	//round(($stats->hashrate_bad*(100-$percent) + $pool_rate_bad*$percent) / 100);

So at this point it looks like a statistical reporting error somewhere

I think this is what I have been mentioning before =)

[AngryDwarf]

This seems to be the code that calculates the percentage share rate. I can't see any obvious calculation error here that would cause that apparent 80% cap we was seeing the other day.

https://github.com/tpruvot/yiimp/blob/yiimp/web/yaamp/modules/site/results/wallet_miners_results.php

Code:

$user = getuserparam(getparam('address'));
if(!$user) return;
echo "<div class='main-left-box'>";
echo "<div class='main-left-title'>Miners: $user->username</div>";
echo "<div class='main-left-inner'>";
echo "<table  class='dataGrid2'>";
echo "<thead>";
echo "<tr>";
echo "<th align=left>Summary</th>";
echo "<th align=right>Miners</th>";
echo "<th align=right>Shares</th>";
echo "<th align=right width=80>Hashrate*</th>";
echo "<th align=right width=60>Reject*</th>";
echo "</tr>";
echo "</thead>";
foreach(yaamp_get_algos() as $algo)
{
//	debuglog($algo);
	$user_rate1 = yaamp_user_rate($user->id, $algo);
	$user_rate1_bad = yaamp_user_rate_bad($user->id, $algo);
	$percent_bad = ($user_rate1 + $user_rate1_bad)? $user_rate1_bad * 100 / ($user_rate1 + $user_rate1_bad): 0;
	$percent_bad = $percent_bad? round($percent_bad, 1).'%': '';
	$user_rate1 = $user_rate1? Itoa2($user_rate1).'h/s': '-';
	$minercount = getdbocount('db_workers', "userid=$user->id and algo=:algo", array(':algo'=>$algo));
	$user_shares = controller()->memcache->get_database_scalar("wallet_user_shares-$user->id-$algo",
		"select sum(difficulty) from shares where valid and algo=:algo and userid=$user->id", array(':algo'=>$algo));
	if(!$user_shares && !$minercount) continue;
	$total_shares = controller()->memcache->get_database_scalar("wallet_total_shares-$algo",
		"select sum(difficulty) from shares where valid and algo=:algo", array(':algo'=>$algo));
	if(!$total_shares) continue;
	$percent_shares = round($user_shares * 100 / $total_shares, 4);
	echo "<tr class='ssrow'>";
	echo "<td><b>$algo</b></td>";
	echo "<td align=right>$minercount</td>";
	echo "<td align=right width=100>{$percent_shares}%</td>";
	echo "<td align=right width=100><b>$user_rate1</b></td>";
	echo "<td align=right>$percent_bad</td>";
	echo "</tr>";
}
echo "</table>";

EDIT: and the underlying sql table, so maybe something going screwy in the memcache?

Code:

DROP TABLE IF EXISTS `shares`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `shares` (
  `id` bigint(30) NOT NULL AUTO_INCREMENT,
  `userid` int(11) DEFAULT NULL,
  `workerid` int(11) DEFAULT NULL,
  `coinid` int(11) DEFAULT NULL,
  `jobid` int(11) DEFAULT NULL,
  `pid` int(11) DEFAULT NULL,
  `time` int(11) DEFAULT NULL,
  `error` int(11) DEFAULT NULL,
  `valid` tinyint(1) DEFAULT NULL,
  `extranonce1` tinyint(1) DEFAULT NULL,
  `difficulty` double DEFAULT '0',
  `algo` varchar(16) DEFAULT 'x11',
  PRIMARY KEY (`id`),
  KEY `time` (`time`),
  KEY `algo1` (`algo`),
  KEY `valid1` (`valid`),
  KEY `user1` (`userid`),
  KEY `worker1` (`workerid`),
  KEY `coin1` (`coinid`),
  KEY `jobid` (`jobid`)
) ENGINE=InnoDB AUTO_INCREMENT=248001 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

Further edit: Share database writes are handled by the stratum c++ processes. So the alternative explanation for the strange share percentage could be a stratum process bug inserting some rubbish into the table.

https://github.com/tpruvot/yiimp/blob/yiimp/stratum/share.cpp

Code:

void share_write(YAAMP_DB *db)
{
	int pid = getpid();
	int count = 0;
	int now = time(NULL);

	char buffer[1024*1024] = "insert into shares (userid, workerid, coinid, jobid, pid, valid, extranonce1, difficulty, time, algo, error) values ";
	g_list_worker.Enter();

	for(CLI li = g_list_worker.first; li; li = li->next)
	{
		YAAMP_WORKER *worker = (YAAMP_WORKER *)li->data;
		if(worker->deleted) continue;

		if(count) strcat(buffer, ",");
		sprintf(buffer+strlen(buffer), "(%d, %d, %d, %d, %d, %d, %d, %f, %d, '%s', %d)",
			worker->userid, worker->workerid, worker->coinid, worker->remoteid, pid,
			worker->valid, worker->extranonce1, worker->difficulty, now, g_stratum_algo, worker->error_number);

		if(++count >= 1000)
		{
			db_query(db, buffer);

			strcpy(buffer, "insert into shares (userid, workerid, coinid, jobid, pid, valid, extranonce1, difficulty, time, algo, error) values ");
			count = 0;
		}

		object_delete(worker);
	}

	g_list_worker.Leave();
	if(count) db_query(db, buffer);
}

[crackfoo]

Hello Crackfoo

LTC payments?  

They should be sent out but I'd suggest using another currency since we're no where near enough hashrate to be hitting and ltc blocks

[AngryDwarf]

Hello Crackfoo

LTC payments?  

They should be sent out but I'd suggest using another currency since we're no where near enough hashrate to be hitting and ltc blocks

Perhaps some of the popular POW coins could be setup similar to how the new POS payout coins have been added? I've noticed the system is saying we are around 5.0 short on dash. That's 2 blocks needed. And I bet plenty of people are still mining it.

[patinencomun]

Hello,
for one of my rigs I have a constant message

 Waiting for work to be available from pools.
 Work available from pools, resuming.
 Waiting for work to be available from pools.
 Work available from pools, resuming.

between any accepted share.
Any suggestion to fix that?

Thank you in advance.

[AngryDwarf]

snip

Just set this pool up on my switcher today and was noticing that payouts seemed oddly a bit lower than expected; perhaps this share distribution thing is the culprit. Right now I've set my software to lower its estimates for the pool, but I'll be keeping an eye on this issue.

EDIT: Just looking at that snippet compared to YIIMP's code, it does seem like the hashrate distribution might indeed be set to function under the assumption that there is a 20% pool fee, rather than the intended 2%. In the original code from YIIMP, $percent is set to 1, which is what their fee is.

It seems like a very strange way of calculating it to me, and hopefully just a statistical reporting error. It might explain though why my reported hash rate is generally lower than my miner output. However, when solo mining an unpopular algo, I think the formula adds up to 100%, not 80%. So there must be another strange calculation reporting the percentage somewhere.
Profitability has been lower for me over the last few hours. Be careful how you get your profitability stats. The ones on the main algo page are a different kettle of fish to those under the pool page.

I've been looking into the YAAMP profitability function further. Basically one of my miners has turned into a chaincoin c11 miner almost fulltime. The pool profitability figure for that coin always looks good (0.5-0,6) so my algo switching miner tends to stay on it. However, the main wallet algo page shows a much lower actual past 24 hour profitability figure (~0.22). The markets lookup code stores 2 prices, price basically being the mid price, and price2 which is basically the bid price. (its applied through some AverageIncrement function that I have yet to find.) Profitabilty is obtained from the coin price, which also has a price2. I don't know how this is populated yet. Chaincoin is basically a junk coin in marketcap terms (in fact I would call most alt coins junk coins), so probably like a lot of unpopular coins has a very wide market spread. Whilst I've yet to really get my head around this code, I think what is happening is that we are choosing coins to mine based on the mid price, trying to sell at that price and slowly adjusting the price down until it gets executed. My personal opinion is that this system is basically a market dumper, and should be choosing mining profitability based on bid price, with any better price achieved a bonus. Also our mid price market sell orders will then lower the mid price, decreasing profitability and causing a switch to another coin. Just note that you cannot take my impressions as gospel!

EDIT: Might have got the two prices the wrong way around above.

But WTF - In all my years of working on financial trading systems I have never come across any kind of arbitrary logic like this, and I am really having difficulty understanding the reason for the price manipulation:

https://github.com/tpruvot/yiimp/blob/yiimp/web/yaamp/core/backend/markets.php

Code:

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

Code:

		$price2 = ($ticker->result[0]->Bid+$ticker->result[0]->Ask)/2;
		$market->price2 = AverageIncrement($market->price2, $price2);
		$market->price = AverageIncrement($market->price, $ticker->result[0]->Bid);

Why not just run of the bid price? That's how long financial market positions are typically valued. Thats the price you will get if looking for a quick exchange.

Disabled c11 for now to see how profitability goes not being stuck on that algo.

Another EDIT: Perhaps it is trying to provide some kind of market price change smoothing function?

[jaggard]

I've yet to see a payment from the other day... If anyone else could take a look and see if their status page shows similar behavior to mine I'd appreciate it. http://www.zpool.ca/?address=18855moCFBjUuFqfwP4xYACefZZ2nqDrSU
As you can see, as soon as I started mining again, it dropped the ~30,000 sats it showed from previous balance, and it went poof as far as I can tell. And, if you look, you can see it just recently did it again to my confirmed balance, when it was showing ~.0015 for total confirmed/unconfirmed, now it's back to showing ~.001. Honestly I'm wondering if I'm the only one this is happening to. I really like the premise of the pool, but if I'm not getting paid, I'll definitely not stick around, and I'll recommend against using the pool to anyone else as well...

I should have gotten at least .005 from the mining the other day, yet I still haven't gotten a response from crackfoo about it other than reply here that it would show up when the coins reappeared, which it obviously hasn't, as you can see by lack of a paid amount on that address.

[crackfoo]

Hello,
for one of my rigs I have a constant message

 Waiting for work to be available from pools.
 Work available from pools, resuming.
 Waiting for work to be available from pools.
 Work available from pools, resuming.

between any accepted share.
Any suggestion to fix that?

Thank you in advance.

Can't say I've seen this error before. Are you setting your own diff?

[crackfoo]

I've yet to see a payment from the other day... If anyone else could take a look and see if their status page shows similar behavior to mine I'd appreciate it. http://www.zpool.ca/?address=18855moCFBjUuFqfwP4xYACefZZ2nqDrSU
As you can see, as soon as I started mining again, it dropped the ~30,000 sats it showed from previous balance, and it went poof as far as I can tell. And, if you look, you can see it just recently did it again to my confirmed balance, when it was showing ~.0015 for total confirmed/unconfirmed, now it's back to showing ~.001. Honestly I'm wondering if I'm the only one this is happening to. I really like the premise of the pool, but if I'm not getting paid, I'll definitely not stick around, and I'll recommend against using the pool to anyone else as well...

I should have gotten at least .005 from the mining the other day, yet I still haven't gotten a response from crackfoo about it other than reply here that it would show up when the coins reappeared, which it obviously hasn't, as you can see by lack of a paid amount on that address.

How many miners do you have? Just the one? Do you have c=BTC in as your password?

I see this in my logs and it's usually from not detecting the address properly:

[2016-02-12 01:32:15] 18855moCFBjUuFqfwP4xYACefZZ2nqDrSU set to BTC, balance 0
[2016-02-12 02:39:56] 18855moCFBjUuFqfwP4xYACefZZ2nqDrSU set to BTC, balance 0
[2016-02-12 02:46:50] 18855moCFBjUuFqfwP4xYACefZZ2nqDrSU set to BTC, balance 0
[2016-02-12 04:50:25] 18855moCFBjUuFqfwP4xYACefZZ2nqDrSU set to BTC, balance 0
[2016-02-12 06:25:23] 18855moCFBjUuFqfwP4xYACefZZ2nqDrSU set to BTC, balance 0
[2016-02-12 06:41:57] 18855moCFBjUuFqfwP4xYACefZZ2nqDrSU set to BTC, balance 0

make sure all your miners have c=BTC

Thanks

[jaggard]

yes, they are using c=BTC.d=384 for pw. I have 4 s3+, but varying the number of them on the pool, esp with the balance flattening as it has been...

[crackfoo]

yes, they are using c=BTC.d=384 for pw. I have 4 s3+, but varying the number of them on the pool, esp with the balance flattening as it has been...

Use a , between options not a . and double check they are all the same. There is one of them that's causing the reset.