Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 133. (Read 499709 times)
February 12, 2012, 12:26:12 AM
Inaba - just ignore him
February 12, 2012, 12:21:44 AM
So then what encryption would be occurring from my miners to your pool?
Other reason's why SSL is bad:
Law Enforcement Appliance Subverts SSL
http://www.wired.com/threatlevel/2010/03/packet-forensics/
Comodo Hacker: I hacked DigiNotar too; other CAs breached
http://arstechnica.com/security/news/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached.ars
Security Solutions for Beast attack against SSL/TLS Vulnerability
http://thehackernews.com/2011/09/security-solutions-for-beast-attack.html
Other reason's why SSL is bad:
Law Enforcement Appliance Subverts SSL
http://www.wired.com/threatlevel/2010/03/packet-forensics/
Comodo Hacker: I hacked DigiNotar too; other CAs breached
http://arstechnica.com/security/news/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached.ars
Security Solutions for Beast attack against SSL/TLS Vulnerability
http://thehackernews.com/2011/09/security-solutions-for-beast-attack.html
February 11, 2012, 10:19:13 PM
Quote from: Inaba
All traffic is encrypted (with the exception of block traffic, since it's meaningless in terms of security)
From where to where, my miners to your pool?Yes, correct. That data is useless to anyone except you.
Quote
Quote from: Inaba
http://:@us2.eclipsemc.com:8337#US2_EclipseMC http://
It isn't SSL...which is broken by design anyway.http://cryptome.org/0005/ssl-broken.htm
Do we OpenVPN to your pool? 4096bit?
Is my tunnel vision justified?
No, no and no. SSL is not exactly broken by design if you use it in the proper context. The context that link is talking about is someone with virtually infinite resources and authority being able to intercept your traffic - yes, in that context it's "broken." But then again, you have to consider that someone with those resources can gather that information in a number of different ways, so securing against that type of attack is an exercise in futility and expends resources that can be used elsewhere.
What SSL does do is protect against common carrier attacks, as in my ISP or your ISP or someone in between listening in on your communications, or even hijacking it. It's the difference between putting you information on a postcard (no SSL) and putting it in a sealed envelope (SSL). Someone with enough desire to read your letter can open the envelope, but someone has to care enough and have the ability to get at the letter. Whereas anyone who happens by can read your post card.
February 11, 2012, 09:43:49 PM
Quote from: Inaba
All traffic is encrypted (with the exception of block traffic, since it's meaningless in terms of security)
From where to where, my miners to your pool?Quote from: Inaba
http://:@us2.eclipsemc.com:8337#US2_EclipseMC http://
It isn't SSL...which is broken by design anyway.http://cryptome.org/0005/ssl-broken.htm
Do we OpenVPN to your pool? 4096bit?
Is my tunnel vision justified?
February 11, 2012, 10:19:52 AM
We've been using DGM almost from the beginning. We started on prop, but quickly switched to GM for about a month or so then to DGM. The instances of invalids started long, long after we switched to DGM.
In any case, though, yes, the blocks are submitted independently of score calculation (block submittal is handled by bitcoind, score calculation is handled in PHP).
In any case, though, yes, the blocks are submitted independently of score calculation (block submittal is handled by bitcoind, score calculation is handled in PHP).
February 11, 2012, 07:08:32 AM
All this talk about the delay between blocks has me wondering something. It seems like EMC had less than average invalids right up until it switched to DGM (I wasn't using it back then, but there weren't many comments on the forum about them until after the switch). When a new block is found it is submitted before the DGM calculations are performed, correct? If not, the delay in submitting the found block could be costing a lot more than the delay in starting a new one...
February 10, 2012, 11:38:07 PM
Hmm... I will take a look at that bit of code and see if anything is amiss. My new plan may obsolete any fixes I put there, though... I will see if I can have at least a proof of concept working this weekend for the new DGM and block processing routines... I think it will solve both issues at once, I just have to be careful that it doesn't reduce precision for score keeping.
February 10, 2012, 10:49:18 PM
The 1500 days thing is just a display issue (it's an uninitialized date field in the database basically) - I'm not sure what you mean about a 1% loss, can you clarify?
I got 1% just by taking 2 minutes x 7 blocks a day / 1440 minutes in a day. Two minutes is a guess but it seems to take about that long for the new block to start. If it was a network problem between the miners and the pool the new block should still start right away. I'm assuming that's why the 1500 comes up, because it has no value until the block starts. I was watching a couple times, while refreshing the block page. As soon as it sets back to zero the shares stopped showing as rejected. February 10, 2012, 09:19:53 PM
The 1500 days thing is just a display issue (it's an uninitialized date field in the database basically) - I'm not sure what you mean about a 1% loss, can you clarify?
February 10, 2012, 09:10:25 PM
I'm still having issues with server communication. It seems that whenever we solve a block, I cannot communicate with the servers for a few minutes, tried all the servers, us1/2/3, tried various miners, kernels and internet connections. While it's not a problem for the most part, there is the problem when we solve a fast block, it can be very possible for me not to be able to submit any shares. My connection works fine for everything else, so I think it might be something to do with me connecting to the US servers from Europe, and when we solve a block, and new work has to be distributed, the fact that I'm in Europe, might be reason why I can't come through the "congested" route. At least that is my idea, been watching it happen every single time we solve a block now, this did not occur at my previous pool (MMC).
Yeah, Ive seen this issue w/ EMC for a while, its like the pool lags out a bit when it solves a block. Thats the only time I get really high stales is after EMC actually solves the block.
Im in the US
February 10, 2012, 05:14:22 PM
Yeah, I will definitely need some testing on it. Maybe I can have something up this weekend, but I'm not guaranteeing it
February 10, 2012, 05:10:05 PM
I have the beginnings of a solution in my head for the new block problem, so it's something I will be working on in the immediate future. It's going to require some changes to the way DGM is handled, so I need to do a lot of testing and checking before I put that type of fix into place.
If you need some help with testing, when it gets so far, let us know, I'm sure some of us would be happy to contribute.
February 10, 2012, 03:44:43 PM
I have the beginnings of a solution in my head for the new block problem, so it's something I will be working on in the immediate future. It's going to require some changes to the way DGM is handled, so I need to do a lot of testing and checking before I put that type of fix into place.
February 10, 2012, 02:20:36 PM
I've ordered some additional hardware that may help out with this, but it may not make a difference to this particular problem. I think it may stem from the way EMC handles DGM when a new block starts, there's a bucket load of DB activity setting up the new miners for the new block, and there may be some queries that are holding everyone else up. I will investigate that as well as how to best leverage the new hardware.
Crossing my fingers
Same here
It certainly would be nice to get that fixed February 09, 2012, 11:43:18 PM
Wow, yeah, I just noticed that I get a ton of stales (rejects) at the beginning of a new block as well. West coast USA here. Kind of a bummer 
February 09, 2012, 10:06:19 PM
I've ordered some additional hardware that may help out with this, but it may not make a difference to this particular problem. I think it may stem from the way EMC handles DGM when a new block starts, there's a bucket load of DB activity setting up the new miners for the new block, and there may be some queries that are holding everyone else up. I will investigate that as well as how to best leverage the new hardware.
Crossing my fingers
February 09, 2012, 06:14:56 PM
I've ordered some additional hardware that may help out with this, but it may not make a difference to this particular problem. I think it may stem from the way EMC handles DGM when a new block starts, there's a bucket load of DB activity setting up the new miners for the new block, and there may be some queries that are holding everyone else up. I will investigate that as well as how to best leverage the new hardware.
February 09, 2012, 05:54:17 PM
I'm still having issues with server communication. It seems that whenever we solve a block, I cannot communicate with the servers for a few minutes, tried all the servers, us1/2/3, tried various miners, kernels and internet connections. While it's not a problem for the most part, there is the problem when we solve a fast block, it can be very possible for me not to be able to submit any shares. My connection works fine for everything else, so I think it might be something to do with me connecting to the US servers from Europe, and when we solve a block, and new work has to be distributed, the fact that I'm in Europe, might be reason why I can't come through the "congested" route. At least that is my idea, been watching it happen every single time we solve a block now, this did not occur at my previous pool (MMC).
Yeah, Ive seen this issue w/ EMC for a while, its like the pool lags out a bit when it solves a block. Thats the only time I get really high stales is after EMC actually solves the block.
Im in the US
February 09, 2012, 02:18:34 PM
I'm still having issues with server communication. It seems that whenever we solve a block, I cannot communicate with the servers for a few minutes, tried all the servers, us1/2/3, tried various miners, kernels and internet connections. While it's not a problem for the most part, there is the problem when we solve a fast block, it can be very possible for me not to be able to submit any shares. My connection works fine for everything else, so I think it might be something to do with me connecting to the US servers from Europe, and when we solve a block, and new work has to be distributed, the fact that I'm in Europe, might be reason why I can't come through the "congested" route. At least that is my idea, been watching it happen every single time we solve a block now, this did not occur at my previous pool (MMC).
February 09, 2012, 01:31:04 PM
So it looks like the problem is here: 68.85.38.86
I'm not sure who owns that, probably comcast, but it appears that router has some weird routing loop going on when connecting to 208.110.68.0/24.
I'm not sure who owns that, probably comcast, but it appears that router has some weird routing loop going on when connecting to 208.110.68.0/24.
Comcast said they had to turn off something to do with smart packets.
Now I'm back to mining and it's good to be getting some warmth from my rig under my bench.
Jump to: