[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 132.

Inaba

legendary

Activity: 1260

Merit: 1000

Quote from: check_status on February 12, 2012, 12:21:44 AM

So then what encryption would be occurring from my miners to your pool?

None, because there is no need. As I said, any mining data is completely useless to anyone but you.

Quote

Other reason's why SSL is bad:
Law Enforcement Appliance Subverts SSL
http://www.wired.com/threatlevel/2010/03/packet-forensics/

Again, anyone with the resources can get that data via other means, so SSL's robustness is irrelevant. It could be perfectly unbreakable and the data could be gathered via a keylogger, spyware of many sorts, endpoint data gathering, rubber hose, etc... When it comes to the government/LEO, SSL is not intended to prevent them from gathering the data, since they have the resources and/or authority to gather it via other means.

Quote

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

Nothing to do with SSL. This is a problem with a company.

Quote

Security Solutions for Beast attack against SSL/TLS Vulnerability
http://thehackernews.com/2011/09/security-solutions-for-beast-attack.html

Looks like a theoretical attack that would require substantial access to a datastream.

But at any rate, what is it that you want to know with regards to EMC?

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Inaba - just ignore him

check_status

full member

Activity: 196

Merit: 100

Web Dev, Db Admin, Computer Technician

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

Inaba

legendary

Activity: 1260

Merit: 1000

Quote from: check_status on 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?

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? Cheesy

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.

check_status

full member

Activity: 196

Merit: 100

Web Dev, Db Admin, Computer Technician

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? Cheesy

Is my tunnel vision justified?

Inaba

legendary

Activity: 1260

Merit: 1000

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).

The00Dustin

hero member

Activity: 807

Merit: 500

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...

Inaba

legendary

Activity: 1260

Merit: 1000

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.

cuz0882

sr. member

Activity: 392

Merit: 250

Quote from: Inaba on 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?

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.

Inaba

legendary

Activity: 1260

Merit: 1000

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?

cuz0882

sr. member

Activity: 392

Merit: 250

Quote from: GenTarkin on February 09, 2012, 05:54:17 PM

Quote from: cyberlync on 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).

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

The round duration on the block stats page goes to something like 1500 days when it happens. I don't think a communications problem could cause that. It's not a huge problem but at 2 minutes a block, it comes out to about 1% loss.

Inaba

legendary

Activity: 1260

Merit: 1000

Yeah, I will definitely need some testing on it. Maybe I can have something up this weekend, but I'm not guaranteeing it

cyberlync

full member

Activity: 226

Merit: 100

Quote from: Inaba on 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.

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.

Inaba

legendary

Activity: 1260

Merit: 1000

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.

e21

member

Activity: 105

Merit: 10

Quote from: cyberlync on February 09, 2012, 10:06:19 PM

Quote from: Inaba on 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.

Crossing my fingers

Same here

It certainly would be nice to get that fixed

freshzive

sr. member

Activity: 447

Merit: 250

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 Sad

cyberlync

full member

Activity: 226

Merit: 100

Quote from: Inaba on 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.

Crossing my fingers

Inaba

legendary

Activity: 1260

Merit: 1000

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.

GenTarkin

legendary

Activity: 2450

Merit: 1002

Quote from: cyberlync on 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).

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

cyberlync

full member

Activity: 226

Merit: 100

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).

Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 132. (Read 499835 times)