Any news on when the change over is going to happen?
It's been pushed back a little bit due to illness. It will be announced clearly on the website when it happens. Feel better dude. -Dave |
|
|
|
Meanwhile, a smaller pool in that same time frame may be much lower, or much higher than neutral.
Which sometimes is part of the "fun" EMC had a block that took 1 day 13 hrs that solved yesterday. Since then 6 in about 18 hours. -Dave |
|
|
|
|
If you look at the ghash #'s over the last day they have had three 2+ hour times w/o a block and seven 1+ hour times w/o a block. Since they have about 3x the hashing power as BTC Guild that would that be the same as three 6+ hour blocks here and seven 3+ hour blocks?
-Dave
|
|
|
|
Well, if we want to entertain the idea of faulty hardware having some bearing on the overall results, we need to identify recent release's. I follow a number of the Antminer threads and see a significant number of miners struggling to keep the S2's up and running. Also see a significant number of S2 miners posting screen shots with concerns over large numbers of Hardware Errors and Rejects. Some one will do a little math and say...Mheee...that's not too bad. My point though is that is 1TH/s equipment and those rejects and errors accumulated in 2-3hrs exceed my accepts for a given time period. AND knock-off miners with slightly less advertised total hash speed from Bit-Mine seem to have a slightly higher error rate/hour as well. Just seems too me like these units are a bit off, maybe they are putting out some bad vibe static.......
If the problem is related to the difficulty going above the limits of a 32-bit variable, it may not have anything to do with *recent* hardware releases. It could be OLD hardware. It would likely be firmware or software in the controller for the hardware. (See edit for more info). This would explain why these accounts were not noted the last time I did a pass. I was looking for active withholding previously. Accounts with significantly low block submissions vs shares submitted. Last night's pass was specifically targetting shares vs blocks over the last 6 weeks, eliminating the chance of past luck making up for recent shortfalls. EDIT/CLARIFICATION: The hardware itself has no reason to actually know the result of its hashing outside of diff>=1 (or >=1024 in some newer hardware I believe). It's probably not in the software since *most* ASICs do not use custom software, they use cgminer or bfgminer. So the point in the middle that handles communication between the hardware and the software is the most likely culprit. There have been many issues with chips though the years. Both ASICs and regular processors. The Intel FDIV bug to the huge errata lists on some RISC processors tend to be more impressive then ASICs, but that is because they are more in the public eye. Do you think that the get it out as fast as you can hardware that we are using is *really* that well tested.... -Dave Still love this error list from the old days (the 5th one down is my favorite) you could blow your hardware with bad code: The Amstrad Plus ASIC improved a lot of the old CPC's capability. Yet this was a bit flawed. Despite removing some tasks from the CPU (Z80), ASIC registers are mapped onto memory from #4000 to #7FFF range prior to other type of memory (RAM or ROM).That means this memory range is not accessible when ASIC registers are paged. PPI emulation is not correct as the original 8255 does not need validation.On ASIC emulation , this validation is needed so some programs written for "old CPCs" will not be able to get keyboard state. Z80 IM2 mode is bugged.In this mode , the Z80 I register gives the high word for vector table.ASIC gives the low word from IVR and the devices that generate interrupt (raster and DMAs channels).ASIC generates sometimes a bad values and the raster interrupt routine is called instead of DMA0 routine.The reasons of this bug are not known. There is a conflict between programmable interrupts and some CRTC settings (line screen split).That will cause the RAM refresh to stop and the memory content will be quickly corrupted causing machine crash. Reducing Horizontal BLanking could cause another internal conflict when using DMA lists.In the worst case , this conflict can cause irreversible damage to the ASIC. Original CPC colors emulation is not correct. |
|
|
|
I found this in kernel.cpp, line 21 // Hard checkpoints of stake modifiers to ensure they are deterministic
static std::map<int, unsigned int> mapStakeModifierCheckpoints =
boost::assign::map_list_of
( 0, 0xfd11f4e7u )
( 10001, 0xd42268a1u )
( 30001, 0x7e0d6e1eu )
( 50001, 0xa5a4473eu )
( 70001, 0xbe5e3360u )
(100001, 0x6cafeba8u )
(133333, 0x011868fcu )
; Those are PoS checkpoints that shouldn't be there. The first number is block height, the second one modifier checksum. My guess is that whenever someone tries to generate block 10001, it doesn't get accepted since the checksum is different from the hardcoded checkpoint ( 10001, 0xd42268a1u ) To verify if my guess is correct, someone who has been mining could look into his debug.log and see if there's anything like AddToBlockIndex() : Rejected by stake modifier checkpoint height=10001
ERROR: AddToBlockIndex() : Rejected by stake modifier checkpoint height=10001, modifier=0x756f6ca000813145 ERROR: AcceptBlock() : AddToBlockIndex failed ERROR: ProcessBlock() : AcceptBlock FAILED ERROR: BitcoinMiner : ProcessBlock, block not accepted |
|
|
|
I might make an appearance the next time a conference is in Vegas, assuming some of the core devs are there. I just don't want to go through the hassle of a modern day US airport.
Then fly through LGA in New York. It's more 3rd world airport then modern day airport. http://www.travelandleisure.com/articles/americas-worst-airports-2013/3I live here and have to use it a lot. Walking is starting to look like a better option. -Dave |
|
|
|
I have had the same issue the last 2 days as well. Same ip as above, a restart of my ants or cgminer/bfgminer cures it. My miners are in 3 different locations, running differnet software and on different ips all using unique Worker names. Antminer S1, BFL LS, BFL Jala and Red Fury's.
Out of curiosity, do you have Teamviewer installed? I'm a bit more active on this on the Eligius thread, but I don't have TeamViewer installed. -Dave |
|
|
|
I spent the better part of the day investigating this issue. - It's not a pool side hack - No pool servers are or were compromised
- It's not a pool-side close network hack - No datacenter infrastructure is compromised
- It only affects certain clients, is not pool wide, and affects affected clients repeatedly
Presumably there is some issue with some client side routing hardware that is being exploited. Anyone effected, please post how your connected to the net. PC->Router->Cable Modem, etc, with makes/models of such so we can possibly narrow this down. #1 2 S1's behind an old linksys running DD-WRT (V24-sp2) Our own IP space (Juniper running BGP) #2 1 S1 running behind a TRENDnet TW100-BRV214 However a few Technobits running on a TL-MR3020 pointing to BTC were not hit On cable #3 S1 and a generic Avalon behind a ZuniConnect router pointing to GHash were hit. On cable. -Dave |
|
|
|
As a miner side fix you can block that IP on your firewall (ideally at the router but even the windows firewall should work for some types of miners). If your miner gets redirected it should be unable to connect to the pirate pool and then switch to whatever you have configured for a failover.
Holy crap, that's so obvious I can't believe I didn't think of that. You would not believe the route I was going to stop this from happening. -Dave |
|
|
|
This jumping to 46.28.205.80 happens on ghash too... And every time at same time... So it might be something automatic...
17 rigs, 3 locations
What software were you using to connect? -Dave |
|
|
|
And I just noticed the share difficulty on the ant was set to 1K.
Has anyone else noticed this?
-Dave
Sounds like you're MITM'd... I *knew* that, just trying to post more info. If it's a 1K share difficulty it's not like they are getting any work out of it. AND also that it was on ghash not just yours as Mr.Teal (slush) mentioned so it's a few more data points. -Dave |
|
|
|
|
And I just noticed the share difficulty on the ant was set to 1K.
Has anyone else noticed this?
-Dave
|
|
|
|
I should probably mention again that I say something like this with a machine that was pointed to Slush. As I speak I just noticed that two rigs in physically separate locations and with different ISPs that were connected to Slush haven't submitted a share in 10 minutes.
The miners show them still connected to pool 0, but 46.28.205.80 instead of Slush.
One was running cgminer 4.0.0 on windows, the other is running cgminer 4.2.2
My test boxes which were pointing to ghash just did this too. What DNS server (s) are you using public or private? What kind of firewall were they behind? One was an ANT S1 the other was an generic avalon clone. Both are running the openwrt / cgminer that came with it. -Dave |
|
|
|
I said that 4 hours ago  It worked until I you someone broke it. -Dave |
|
|
|
|
Last block was # 10000 over 5 hours ago, something happen?
-Dave
|
|
|
|
|
Anyone in NY using Optimum having issues getting to Eligius to mine? I can get to the website and 2 of my miners on another network are working no problem but the cable one cannot. It gets to BTC and EMC no problem, but not the Eligius.
-Dave
|
|
|
|
|
Show Posts
