Topic: █▓▒░-< [ZPOOL.CA][BTC Multipool] The miners multipool >-░▒▓█ Paid 925+ BTC - page 18. (Read 217685 times)
September 03, 2016, 02:15:08 AM
EDIT: Taking a more close look there is a jump in my balance graph that seems to be that share being paid, but without blocks mined being shown in the found blocks list. Is anyone seen something similar (so no lack of payment, lack of mined block refresh instead)
September 03, 2016, 02:07:29 AM
Anyone else notice that a lot of coins are taking an abnormally long time to go from New to Immature and actually show up that you mined them?
It happens sometimes but 2 hours behind is unusual. Something must be stuck.
There was a block record that was corrupted so block processing was down until it was removed. It running through now, but there was about 6000 blocks to process.
But all that blocks where not valid or what? I have lost my share in the algos I mined during the stuck time without receive any payment. So if the blocks where valid I have been mining two hours for the pool for free. Not fair.
September 03, 2016, 01:28:29 AM
price2 is the ask (sell) price which is there for information and/or initial sale orders in auto exchange mode. A big difference between both generally means the exchange is not used enough.
The used one for estimations is price. And the "avg increment" is there to prevent some instant peaks, that make the curve more "flat"
The used one for estimations is price. And the "avg increment" is there to prevent some instant peaks, that make the curve more "flat"
September 02, 2016, 09:48:23 PM
Anyone else notice that a lot of coins are taking an abnormally long time to go from New to Immature and actually show up that you mined them?
It happens sometimes but 2 hours behind is unusual. Something must be stuck.
There was a block record that was corrupted so block processing was down until it was removed. It running through now, but there was about 6000 blocks to process.
September 02, 2016, 09:32:47 PM
Anyone else notice that a lot of coins are taking an abnormally long time to go from New to Immature and actually show up that you mined them?
It happens sometimes but 2 hours behind is unusual. Something must be stuck.
September 02, 2016, 09:27:51 PM
also remember the coin price = buy orders ... only 
Also the quoted price is based on the last trade so if the last trade was at the buy price there would be no spread discrepency.
Is it? The estimates are, AFAIK, based off the ASK price. The pool sells into the BIDs.
Most exchanges quote the last price as the price of the last trade. They can also quote bid and ask. If the pool is
specifically requesting the ask price it's misleading if you are selling into the bid. If you are placing market sell
orders you will always be getting the bid price so it would be more appropriate to use the bid price in your
estimates. Can you change it?
Edit:
The choice of exchange could also be a factor. If the pool is choosing among all the connected exchanges
how does it choose? If quoting ask prices and choosing the highest ask price it woul dfurther distort the estimate
from the actual trade, particularly if quoting a low volume exchange where higher price spreads are likely.
Quoting the highest bid, or the bid with the most volume, seems the best approach as this is most likely going
to be the trade price.
I did some of the grunt work.
Here is a sample for Poloniex. Other exchanges have similar code. It looks like the estimate is based on either the bid price
or the average of the bid and ask price, depending on whether it uses price or price2. I don't know what AverageIncrement does.
It also appears to look for the best market. It doesn't look like this is the problem.
https://github.com/tpruvot/yiimp/blob/next/web/yaamp/core/backend/markets.php
Code:
$price2 = ($ticker['highestBid']+$ticker['lowestAsk'])/2;
$market->price2 = AverageIncrement($market->price2, $price2);
$market->price = AverageIncrement($market->price, $ticker['highestBid']);
$market->pricetime = time();
September 02, 2016, 09:09:17 PM
There are weird things happening in the pool rigth now. I'm minning algos which theoretically are not finding blocks, so I'm accumulating shares
But when I enter in that algo tab, the pool is getting coins, but it's not able to confirm them.
Hope you can solve this fast, crackfoo. I will stop mining till then.
But when I enter in that algo tab, the pool is getting coins, but it's not able to confirm them.
Hope you can solve this fast, crackfoo. I will stop mining till then.
September 02, 2016, 08:53:16 PM
Anyone else notice that a lot of coins are taking an abnormally long time to go from New to Immature and actually show up that you mined them?
legendary
Activity: 1848
Merit: 1166
My AR-15 ID's itself as a toaster. Want breakfast?
September 02, 2016, 08:08:29 PM
I may write myself a program to take the pool's share percentage and calculate that into what algo to mine;
When I switch my miners to 100% an algo that is profitable but I get 15%+ share on a low number of miners; I seem to get crazy wicked profit spikes.
I want an app that will take advantage of this.
Sitting on XRE for the last 24 hours has been very nice... Seeing 10%-25%+
When I switch my miners to 100% an algo that is profitable but I get 15%+ share on a low number of miners; I seem to get crazy wicked profit spikes.
I want an app that will take advantage of this.
Sitting on XRE for the last 24 hours has been very nice... Seeing 10%-25%+
September 02, 2016, 10:37:56 AM
also remember the coin price = buy orders ... only
Also the quoted price is based on the last trade so if the last trade was at the buy price there would be no spread discrepency.
Is it? The estimates are, AFAIK, based off the ASK price. The pool sells into the BIDs.
Most exchanges quote the last price as the price of the last trade. They can also quote bid and ask. If the pool is
specifically requesting the ask price it's misleading if you are selling into the bid. If you are placing market sell
orders you will always be getting the bid price so it would be more appropriate to use the bid price in your
estimates. Can you change it?
Edit:
The choice of exchange could also be a factor. If the pool is choosing among all the connected exchanges
how does it choose? If quoting ask prices and choosing the highest ask price it woul dfurther distort the estimate
from the actual trade, particularly if quoting a low volume exchange where higher price spreads are likely.
Quoting the highest bid, or the bid with the most volume, seems the best approach as this is most likely going
to be the trade price.
September 02, 2016, 10:04:44 AM
also remember the coin price = buy orders ... only
Also the quoted price is based on the last trade so if the last trade was at the buy price there would be no spread discrepency.
Is it? The estimates are, AFAIK, based off the ASK price. The pool sells into the BIDs.
September 02, 2016, 09:59:49 AM
also remember the coin price = buy orders ... only
Yup, already considered that. A 20% spread might be possible for a couple of very very low volume coins
but it can't explain a consistent 20% bias. Also the quoted price is based on the last trade so if the
last trade was at the buy price there would be no spread discrepency.
Do you have any tips for data collection to trace the process from the time a block is found until it is sold?
Until we have real data it's all just speculation based on superficial observations. The question of what is causing
the apparent loss of 20% needs to be answered one way or another.
September 02, 2016, 06:05:15 AM
also remember the coin price = buy orders ... only
September 01, 2016, 04:21:25 PM
@joblo
You're right in that it is out of context; however, this type of board isn't really the right space to provide the 9 different pages that form to create the graphed estimates. That being said, you're still missing the point that since the estimates are calculated on a time and hashrate basis, by definition, they include the notion of continued mining. No one on Earth is going to create an estimate formula for on-again/off-again mining; the entire notion is ridiculous.
@everyone crying about the feken graph
Stop blaming the pool op because you don't like 1 small function of the 12 bajillion lines of prewritten code he employs. Suck it up, buttercup, and mine on. If you don't like it (and every yiimp pool on the planet), then write your own!
You're right in that it is out of context; however, this type of board isn't really the right space to provide the 9 different pages that form to create the graphed estimates. That being said, you're still missing the point that since the estimates are calculated on a time and hashrate basis, by definition, they include the notion of continued mining. No one on Earth is going to create an estimate formula for on-again/off-again mining; the entire notion is ridiculous.
@everyone crying about the feken graph
Stop blaming the pool op because you don't like 1 small function of the 12 bajillion lines of prewritten code he employs. Suck it up, buttercup, and mine on. If you don't like it (and every yiimp pool on the planet), then write your own!
Continued mining disguises the problem by adding another cariable. It's very simple actually. Mine lbry until you get a block. Now your
wallet has a share of one block of one coin. Stop mining imediatelty. If everything was static the value would remain the same, ie the
graph would be perfectly flat. But the coin's exchange price isn't static because you will notice the value fluctuate. Then the coin matures
and gets exchanged and 20% is lost.
If the value of the coin was not being updated the graph would stay flat as the coin matures because there are no other coins being added
or exchanged, just a share of one block of lbry. If that was the case there could be a significant difference between the hours-old estimate and
the current rate. But a consistent 20% no matter the coin is too much of a stretch. But that's not what I see.
I see the value fluctuating as the coin matures. Why is it doing that? I still have the same number of lbry so why is the value changing. Obviously
the exchange rate is being updated. If the exchange rate is regularly updated there should be no reason for a large discrepency when the coin
is ultimately sold.
Continued mining, which you're hung up on, just complicates things so it's harder to see the problem. I think crackfoo realizes there is an issue
but doesn't know what to do about it. But you're just in denial. Why are your denials so forceful yet so superficial without any supporting evidence.
Why are you so sure you're right? Why are you so sure I, and others, are wrong?
I've explained my position in great detail and anyone with the tools and the data can prove me right or wrong. I am willing to help in any way I can.
If there is a problem we all will benefit from getting it fixed, except maybe someone who is profiting from it.
September 01, 2016, 02:36:41 PM
What was the reason to remove Bitboss sha256, it seems now we need to take advantage of its current value
Blockexplorer: http://blocks.ypool.ga:2003
Dead
And the amount of Orphans is insane!!
Not to mention 36 unconfirmed (some "8d ago").Why u still pushing this?
Dev left a long long time ago.
I just saw it on yobit is all lots of pump on that coin right now, went up from 5k sat to 7k sat in 10 minutes
September 01, 2016, 02:29:06 PM
What was the reason to remove Bitboss sha256, it seems now we need to take advantage of its current value
Blockexplorer: http://blocks.ypool.ga:2003
Dead
And the amount of Orphans is insane!!
Not to mention 36 unconfirmed (some "8d ago").Why u still pushing this?
Dev left a long long time ago.
September 01, 2016, 02:15:14 PM
What was the reason to remove Bitboss sha256, it seems now we need to take advantage of its current value
September 01, 2016, 02:08:27 PM
@joblo
You're right in that it is out of context; however, this type of board isn't really the right space to provide the 9 different pages that form to create the graphed estimates. That being said, you're still missing the point that since the estimates are calculated on a time and hashrate basis, by definition, they include the notion of continued mining. No one on Earth is going to create an estimate formula for on-again/off-again mining; the entire notion is ridiculous.
@everyone crying about the feken graph
Stop blaming the pool op because you don't like 1 small function of the 12 bajillion lines of prewritten code he employs. Suck it up, buttercup, and mine on. If you don't like it (and every yiimp pool on the planet), then write your own!
You're right in that it is out of context; however, this type of board isn't really the right space to provide the 9 different pages that form to create the graphed estimates. That being said, you're still missing the point that since the estimates are calculated on a time and hashrate basis, by definition, they include the notion of continued mining. No one on Earth is going to create an estimate formula for on-again/off-again mining; the entire notion is ridiculous.
@everyone crying about the feken graph
Stop blaming the pool op because you don't like 1 small function of the 12 bajillion lines of prewritten code he employs. Suck it up, buttercup, and mine on. If you don't like it (and every yiimp pool on the planet), then write your own!
September 01, 2016, 01:23:07 PM
prove
Code:
$step = 15*60;
$t = time() - 24*60*60;
$stats = getdbolist('db_balanceuser', "time>$t and userid=$user->id order by time");
echo '[[';
for($i = $t+$step, $j = 0; $i < time(); $i += $step)
{
if($i != $t+$step) echo ',';
$m = 0;
if(isset($stats[$j]) && $i > $stats[$j]->time)
{
$m = bitcoinvaluetoa($stats[$j]->balance);
$j++;
}
$d = date('Y-m-d H:i:s', $i);
echo "[\"$d\",$m]";
}
plz give it to crackfoo if that's what screwed up estimates,
i'm not a coder, i register a problem and report it.
thx for help
@ComputerGenie
OK, I'll play along. It looks like code to display the BTC balance over the last 24 hours at 15 minute intervals.
It's interesting but without context. Did you write this or grab it from the pool code?
What would be more interesting is to monitor the pending estimate and the balance over a similar time frame
after a user has stopped mining. The pending line should be flat except it will drop when a coin is sold and there
should be a corresponding rise in the balance.
If the pending estimate varies when there is no mining and no coin sales it must be due to exchange fluctuations.
No coins are being added or removed from the pending so the only thing left, assumingno orphans, is exchange value.
This would prove that the pending estimate is kept up to date with the exchanges.
It also means the sale price should be very close to the last estimate. But that where things go wrong. It appears
we are losing 20% on the sale.
The next step would be to match the balance changes with the actual sell transactions to see if the proceeds of the
transaction match the drop in the estimate (100%) or the rise in the balance (100%-20%).
September 01, 2016, 11:55:04 AM
Decided to tether my cellphone and test the batch today. Works like a champ. Video card selection and all. Makes it nice to have one instance/miner connection per device. More consistent hashrates/shares IMHO. I think ill start running it that way from now on.
I am thinking of finding a simple way to have the batch do this automatically.... but logistically speaking using dos commands: it's a nightmare to do. (dynamic check/verify/logic is hard to accomplish with DOS commands).
I am thinking of finding a simple way to have the batch do this automatically.... but logistically speaking using dos commands: it's a nightmare to do. (dynamic check/verify/logic is hard to accomplish with DOS commands).
You could write the script in any other scripting language like python, bash, perl or php. They all support windows pretty well, AFAIK.
I'm thinking you've reached the limits of a batch file dos command file. You may have to dust off your programming gloves and go for another language. I'll happily beta test whatever you decide to throw at us. Even if you were to program in a 1 time mining fee to your address for 30 seconds or so when you originally start the program until we get it down and operational.
Jump to: