[DOWN] Bitlc.net - P2SH, No invalid blocks, Custom payouts, EU, 0% fee, LP

[Jine]

Ah..

Sorry about that, it was a display error due to round-id's being a bit off because to those -1yr rounds.

The round we're missing is 136012 - not 136008.
The problem is that i do not got a working backup nor sharestats for that round (yet) - so i cannot issue a manual backup until I've solved that OR choosen to pay out 136008 once more.

(I'm not sure how to do yet, I'll give you guys an update on this mater tomorrow.)

--
Regards,
Jim

[1715008677]

1715008677

[1715008677]

1715008677

[1715008677]

1715008677

[yuriyg]

Thanks for the details, Jine. Love the pool, btw!

[deepceleron]

Here is how the round database looked before the transactions were re-sorted.

271    136037    1 552 696    1 590 059  13 Jul 01:00:33    3h 10m     (actually 2h 50m)
270    136008    0 000 000    0 000 000  12 Jul 21:49:57    -1y 12mo  (actually 2h 33m)
269    136012    1 422 937    1 449 703  12 Jul 22:10:23    2h 53m    (actually 20m)
Round start time    12 Jul 19:16:29

Here's my analysis of what happened here:

19:16:29 - Round 269 Starts
21:49:57 - A Block is found, but not correctly added to the database
22:10:23 - Another block is found and recognized, ending Round 269, and user distribution of 50BTC are based on shares since 19:16:29
22:10:23 - The missed block is inserted into the database, causing weird calculations and 0 payments
22:10:23 - Round 271 starts
01:00:33 - Round 271 ends. The length of the round is shown wrong because it looks back at the inserted block. Payments are correct.

So the basic problem is that the shares (user share ratio/total share ratio) for both round 269 and 270 (as listed above) were combined into just round 269.

Since the 1 422 937 shares contributed during both rounds 269 and 270 were only applied to round 269 and cannot be separated now, the fair thing to do is copy round 269's user shares and total shares on block 270 also, giving it the same payout ratio per user. Users can think of this as a longer 100BTC round. The solution is essentially to just double-pay block 269.

[Jine]

I think you're correct, and that's also what we're going to do.

It's an unfortunate event for which a human error was the reason to why it happened in the first place.
I will issue a manual payout for round 269 later today, it will require some scripting and a few tests - but it's on the way.

Thanks for your analysis anyway!

[Jine]

Hi guys!

I just wanted you to know that we're having a planned outage today , more information about that below.

SERVICE WINDOW INFORMATION
Att: Selected Customers
Affected Service(s): XEN01 Node at STO4

We're going to do a planned hardware and software upgrade on the node running the Bitcoins.lc platform.
The hardware upgrade will result in a longer interruption (up to 10-15 minutes) and the software one will only require a quick restart (2-3 minutes).

In total, the service should not be affected for more then 20 minutes.

SERVICE WINDOW DETAILS
WHAT: Planned software and hardware upgrades.
WHEN: Thursday 2011-07-14 @ 18:00 - 18:30 CEST (GMT+02)  -  16:00 - 16:30 GMT
DURATION: A longer interruption while hardware upgrades are being made (up to 15 minutes), and shorter interruptions of service during software upgrades.
SERVICES AFFECTED: All Internet and communication services for customers receiving this notice.

Thanks for your understanding and sorry for the short notice!

--
Best Regards,
Network Operations Center
Jine - http://www.jine.se

[Jack of Diamonds]

I don't think the worker table is accurate at all.

It *always* shows the shares of the last 30 minutes being 1 or 2 higher than currently,
and the numbers are wildly varying across my workers

(For example one worker shows 99 to 98 shares all day, another shows 88 to 89 shares all day, another one 103 to 104,
 despite all of them being identical GPUs at same clock frequencies)

The number per 30 minutes is never higher on the left side of the column which I find hard to believe

[spudhed]

is something wrong with the hash rate calc at the site, i have 2 cards, at my end theyre pumping out 420mh and 402mh each however the site reads as 700mh and has for an hour or so now, is it having issues.

and i know ive asked many times but unless i keep asking itll probably be forgotten: any sign of that api implementation any time soon?

@jackofdiamonds

love your sig dude

[pandemic]

on the site, it says I've got 386mh/s. On my machine I've got one running at 304 and another GPU at 97mh/s. Those figures aren't fluxuating so I'm wondering why that's not matching up with the site.

[spudhed]

well its not my hardware, if i push all my power to another pool it reads out the full amount, were losing some somewhere at lc it seems, unless its just the counter thats off, maybe the scheduled upgrade will fix it

[deepceleron]

on the site, it says I've got 386mh/s. On my machine I've got one running at 304 and another GPU at 97mh/s. Those figures aren't fluxuating so I'm wondering why that's not matching up with the site.

I don't think pools can directly measure your hashrate, they can only see how many shares you have contributed. Shares: you submit difficulty 1 hashes as proof-of-work to a pool, and then the pool checks to see if the hash is also full difficulty, solving a block. Since like full difficulty blocks, shares are a random problem and have variance, in one hour of sampling you may submit more or less shares than your hashrate predicts, plus rejected shares often aren't associated with your worker account and can't be added to the hashrate estimation. The absolute proof of your submitted work is number of shares, which you can verify by logging with your miner.

[Jack of Diamonds]

on the site, it says I've got 386mh/s. On my machine I've got one running at 304 and another GPU at 97mh/s. Those figures aren't fluxuating so I'm wondering why that's not matching up with the site.

I don't think pools can directly measure your hashrate, they can only see how many shares you have contributed. Shares: you submit difficulty 1 hashes as proof-of-work to a pool, and then the pool checks to see if the hash is also full difficulty, solving a block. Since like full difficulty blocks, shares are a random problem and have variance, in one hour of sampling you may submit more or less shares than your hashrate predicts, plus rejected shares often aren't associated with your worker account and can't be added to the hashrate estimation. The absolute proof of your submitted work is number of shares, which you can verify by logging with your miner.

But I find it hard to believe one worker produces 103 shares per 30 minutes for many days, another one does 84, another one does 91, and they are all identical (same clock frequency as well).

The number *never* moves which makes me think the algorithm could be broken. It's too much to be a coincidence since it's been happening for ages (the hashrate, however, does move)

If it was correct like on deepbit, all workers would be within 0.1% of each other in the long term. I'm seeing 20% fluctuations on GPUs that are accepting shares just fine at the same speeds (and the client shows them at nearly identical amounts of accepted shares)

[pandemic]

The whole site is going to be down for 30 min?

[Wolenber]

The whole site is going to be down for 30 min?

It's already back up.

[gellimac]

how can I can to take all my BTC?

I want to change of pool

[padrino]

how can I can to take all my BTC?

I want to change of pool

Login to your account, go to settings and request a payout..

[TheMalon]

14H and 30 min for the current round ... and it didn't finished ... there is somthing strange with the pool software
I've took a look to BTC Mine pool (it have more or less the same hashrate) and it doesn't have so long rounds ...

[TheMalon]

15 hours ... 

[padrino]

Unlucky, it sure looks like it but the occurrences are picking up, without running the numbers it's hard to get a real feel for what is happening but I see from the posts it's raising suspicions.

[Jack of Diamonds]

They do happen every few months on average, but not with this frequency at other pools of similar or even lower size.

After using this pool for so long without issues, I'm having a trust problem after the last ultra-long round breaking share records was revealed to have been "3 different blocks" and there is still a 0 shares unpaid block in the system...

Sudden software bugs? I don't know what to believe. Will move away all miners until at least block 136012 becomes paid.

[Jine]

Jack of Diamonds:
Then you're lucky, wait ~15 minutes for the payment

I'm just home from the datacenter, our upgrade went just fine.
I added another pushpoold-node to the cluster, so we now got 4 load balanced nodes running individually (same architecture as btc guild, identical even)

Give me a few minutes and I'll issue the payout.
These long blocks could be a result of the increased amount of stales we're seeing
(But rest assure, we're working on that to - If i have time, I'll try out our latest patch in our staging environment)

I'll give you guys an update as soon as i got something good