Author

Topic: █▓▒░-< [ZPOOL.CA][BTC Multipool] The miners multipool >-░▒▓█ Paid 925+ BTC - page 140. (Read 217687 times)

legendary
Activity: 3486
Merit: 1126
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
legendary
Activity: 3486
Merit: 1126
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?
newbie
Activity: 29
Merit: 0
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.
sr. member
Activity: 476
Merit: 501
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 Huh - 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?
jr. member
Activity: 76
Merit: 1
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.

sr. member
Activity: 476
Merit: 501
Hello Crackfoo

LTC payments?  Huh Huh Huh


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.
legendary
Activity: 3486
Merit: 1126
Hello Crackfoo

LTC payments?  Huh Huh Huh


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
sr. member
Activity: 476
Merit: 501
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 "
";
echo "
Miners: $user->username
";
echo "
";
echo "";
echo "";
echo "";
echo "";
echo "";
echo "";
echo "";
echo "";
echo "";
echo "";
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 "";
echo "";
echo "";
echo "";
echo "";
echo "";
echo "";
}
echo "
SummaryMinersSharesHashrate*Reject*
$algo$minercount{$percent_shares}%$user_rate1$percent_bad
";

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);
}
legendary
Activity: 1848
Merit: 1166
My AR-15 ID's itself as a toaster. Want breakfast?
@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  Huh

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 =)
sr. member
Activity: 476
Merit: 501
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.
newbie
Activity: 4
Merit: 0
hero member
Activity: 698
Merit: 500
legendary
Activity: 3486
Merit: 1126
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!
legendary
Activity: 3486
Merit: 1126
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.
sr. member
Activity: 476
Merit: 501
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.
sr. member
Activity: 476
Merit: 501
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.
sr. member
Activity: 476
Merit: 501
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;
member
Activity: 97
Merit: 10
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.
sr. member
Activity: 476
Merit: 501
Trying to get my head around this bit of code  Huh

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

Code:
function BackendStatsUpdate2()
{
// debuglog('----------------------------------');
// debuglog(__FUNCTION__);
////////////////////////////////////////////////////////////////////////////////////////////////////
$step = 15;
$tm = floor(time()/$step/60)*$step*60;
$list = dbolist("select userid, algo from shares where time>$tm group by userid, algo");
foreach($list as $item)
{
$stats = getdbosql('db_hashuser', "time=$tm and algo=:algo and userid=:userid",
array(':algo'=>$item['algo'], ':userid'=>$item['userid']));
if(!$stats)
{
$stats = new db_hashuser;
$stats->userid = $item['userid'];
$stats->time = $tm;
$stats->hashrate = dboscalar("select hashrate from hashuser where algo=:algo and userid=:userid order by time desc limit 1",
array(':algo'=>$item['algo'], ':userid'=>$item['userid']));
$stats->hashrate_bad = 0;
$stats->algo = $item['algo'];
}
[b] $percent = 20;[/b]
$user_rate = yaamp_user_rate($item['userid'], $item['algo']);
[b] $stats->hashrate = round(($stats->hashrate*(100-$percent) + $user_rate*$percent) / 100);[/b]
if($stats->hashrate < 1000) $stats->hashrate = 0;
$user_rate_bad = yaamp_user_rate_bad($item['userid'], $item['algo']);
$stats->hashrate_bad = round(($stats->hashrate_bad*(100-$percent) + $user_rate_bad*$percent) / 100);
if($stats->hashrate_bad < 1000) $stats->hashrate_bad = 0;
$stats->save();
}

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
full member
Activity: 343
Merit: 100
Great pool but SHA256 need some work. What happens is I hear the beeping of my Antminer s7's telling me they are offline, so I go to zpool and its kicked all the miners off the pool under that protocol for some reason. The antminers connect eventually but are stuck at 64 difficulty(wow! should be like 16.4K min) At first I thought it was just me but on the site it goes from like 60 Th/s total to zero(kicked everyone)then will climb up to like 2.5 Th/s for a while and I guess as people re-boot their machines or re-connect it will fix the difficulty issue and eventually go back to normal. You may want to look into this. Does the site support extronance extensions like nice hash. My guess is the server is refreshing coin status or something and in the process everyone is kicked. The whole point of a pool is so you can set it on there and it will mine unattended, not have to manually re-connect or re-boot the machines to get back on correctly. It even crashed one of my machines when it got cut. My guess is that at only 64 difficulty at 4.73 Th/s is was doing so many operations it crashed. Is there a way to manually set difficulty? That may be a fast fix when everyone gets kicked off. On your site it says you can set difficulty but it doesn't mention SHA256. I'll try d=16384 and see if it works when we get kicked next.

Edit: Doesn`t work zero shares accepted.
Jump to:
© 2020, Bitcointalksearch.org