Pool shows me much lower hashrate than my miners.
It's a 10 minute average, are you waiting 15 minutes or so for it to become accurate?
|
|
|
Mining LTC still not good, I am staying on Pool-X for the time being.
What's not good exactly?
|
|
|
Yeah I woke up in the middle of the night last night and happened to check the pool, FTC was at 0 hashrate, I figured it was a DB issue or something, went in and there were 1 million shares in the DB, all rejects. Wasn't happening on any other Multipool coin as far as I could tell, so I had to dive into the code and figure out what was going on.. After that it was a fairly easy fix (of which I'm not 100% sure of the implications.. Basically it prevents shares from being submitted from a block too far in the future...? But why would that happen to begin with unless the blockchain was fucked up or your localtime was off? For sure you'd want to prevent shares from past blocks from being submitted in case your client wasn't caught up but thought it was.)
|
|
|
Am I the only one with this.. but with all the happenings with FTC recently, there seems to be an amount of legacy "Unconfirmed" balance in my totals for FTC. Is there a way to promote that balance to be confirmed, or is it to be cancelled as collateral damage?
Those were the orphaned blocks from last night. I said I would pay them so I have. Unfortunately I cannot afford to lose any more FTC which is why the multiport hasn't gone back onto it.
|
|
|
We've gotten 4 orphans so far, if we get 2 more I'm going to take FTC off the multiport.
I read on the feathercoin forum that they were under the impression that you pointed the multiport to FTC to help them counter the 51 attack. Although it was an automatic switch, it could be a good idea. Why not offer altcoin developers the possibility to manually point the multiport to their coin when they are 51 attacked? Obviously they have to compensate you/us for that so we make at least what we would on another coin, but they have big pots of pre-mined coins anyway that they could use for that. It might be a win-win situation. I like this idea, it's similar to something I read in a fictional story in Bitcoin Magazine a few months ago. Basically in the future there will be companies that insure against double spends, and they contract with emergency hashing providers that will mine for them on demand in case of double spends. Only a cryptocoiner with his head up his ass would think this is a good or cool or desirable thing. Why not just have 2 crypto coins that work? You mean ppcoin and novacoin? BTC and LTC are only marginally safer from 51% attacks than most of the alts.
|
|
|
It looks like Amazon is currently experiencing connectivity issues in Europe. I can't connect to the EU pool but it is up and running and I see shares being submitted by some people.
So is it fine ATM? Well, the server is up and the pool software is running.. Any connectivity issues are outside the scope of what I can control.
|
|
|
EDITED: Figured out what's going on w/PXC.. confirmations take awhile 24hr profitability has dropped 25% from last period. May be due to several hours of ftc fuckups. Maybe too many coins, too many changes too fast. I watched the stratum change multiple times every few minutes last night, surely that cannot be good for mining. T. Just a clarification, there are no profitability 'periods' as such, the profitability snapshot is realtime and includes the past 24 hours from the moment you click. The 3 hours of rejects on FTC definitely had a major impact.
|
|
|
It looks like Amazon is currently experiencing connectivity issues in Europe. I can't connect to the EU pool but it is up and running and I see shares being submitted by some people.
|
|
|
what happens with my ftcs in my personal wallet? are they safe?
They should be fine, it doesn't look like the attack was successful beyond orphaning some blocks.
|
|
|
All coins now have a dynamically calculated profit handicap that is based on the current orphan rate and stale rate.
In the case of FTC (where stale rate went to 100%) this should drive profitability down and force the multiport off that coin.
|
|
|
It looks like mintime (ntime) in the FTC client is off by about 6200 seconds, that's what's causing this problem.
As far as I can tell, NVC is not affected. However, I am patching stratum to give greater leeway to ntime across all pools.
|
|
|
Well this is apparently affecting at least one other FTC pool as well. I have fixed the issue by patching stratum to not check ntime (seriously, who cares what time a share thinks it is as long as it is valid?) but I'm keeping FTC out of the multiport for now in case we're on the wrong chain or something.
|
|
|
An hour or more later, :7777 is on FTC again, and this
Rejected xxxxxxxx Diff..... (SHARE SUBMIT Ntime out of r
...repeatedly
comes up again. I'm not coming back until this is addressed.
This is only happening on FTC.. I have taken FTC out of the multiport for now while I try to figure out what is going on.. We are on WDC now and it seems to be fine. Always on the nights I fall asleep early...
|
|
|
Wow your Luckycoin pool efficiency really sucks. My rejects are through the roof too.
When a block is being found every 10 seconds it's hard to be 100% efficient..
|
|
|
One of my miners stops mining a few times a day after displaying "Stratum connection to pool 0 interrupted" it prints two more lines and stops. On my workstation I've occasionally seen that message but it'll recover and go back to mining. Some days a couple other miners freeze. Is there a configuration option or anything I can do to cure that??? TIA
I'm not sure why cgminer (I'm assuming you're using cgminer) sometimes takes a long time to reconnect after the connection has been lost. You would think it would try again immediately but this doesn't seem to be the case.
|
|
|
Should we disable FTK for a while if we suspect there is a 51% going on... ?
Yes, I'm wondering if this has something to do with my issue...miners working 100% fine on all other coins No, it has nothing to do with the stratum auth issue. My question was more about it's profitability if it's under a 51% We've gotten 4 orphans so far, if we get 2 more I'm going to take FTC off the multiport.
|
|
|
flound, wouldn't it be a combination? I thought shares from orphan blocks are what is shown as invalid.
nah, you generally have perfectly valid shares for orphan blocks just like any other (after all its not an orphan until you've solved it and tried to submit it). Most sites I've seen don't really ever distinguish or list shares lost due to orphans (if they are in fact lost, and not just applied to another block). Invalids generally line up with actual rejected shares in your client, orphan block or not. Stale shares are shares that are submitted by the miner after the pool has already detected a new block on the network. They are unavoidable as there will almost always be miners in the middle of a share that don't get the new block notification in time and still try to submit the share. If you want to cut down on stales, you'd have to do work between the pool software and the miner, it has nothing to do with the coin client.
|
|
|
Should we disable FTK for a while if we suspect there is a 51% going on... ?
Yes, I'm wondering if this has something to do with my issue...miners working 100% fine on all other coins No, it has nothing to do with the stratum auth issue.
|
|
|
thanks. weird thing is it worked for a while today and just started with the bad worker credentials. mine fine on other pools. cpuminer with a stratum proxy
edit: seems to be when we went to FTC?
Btw latest version of cpuminer supports stratum I believe. what should I do now? go to new cpuminer version then I won't need the proxy, and it will work? or go to getwork? edit: weird, it started right back up when we got off FTC. ok it happened again. Not sure whether this is what you meant about the bug in stratum, but I can't seem to mine when the pool switches to FTC. EDIT: just switched to new cpuminer and still getting stratum error when it goes to FTC PM or email me your worker name.
|
|
|
Some of my mining stats:
PAID SHARES Your valid: 198920 Invalid: 687
= 0.345% orphan rate.
While it is still in the zeros, it should drop significantly and approach zero as the difficulty stabilizes.
Those are stales, not orphans.
|
|
|
|