Topic: [POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com - page 132. (Read 465668 times)

DDOS attack pointed at wafflepool stratum endpoints.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Administrator>tracert pool1.us.multipool.us

Tracing route to pool1.us.multipool.us [162.243.142.31]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  modem.Home [10.42.0.1]
  2    36 ms    20 ms    23 ms  67.41.239.68
  3    19 ms    19 ms    19 ms  slkc-agw1.inet.qwest.net [67.41.234.25]
  4    47 ms    38 ms    37 ms  snj-edge-03.inet.qwest.net [67.14.34.54]
  5    42 ms    38 ms    38 ms  65.113.42.118
  6    40 ms    37 ms    37 ms  ae0-110g.cr1.sjc1.us.nlayer.net [69.22.143.117]

  7    39 ms    58 ms    39 ms  ae1-70g.cr1.pao1.us.nlayer.net [69.22.143.166]
  8    40 ms    39 ms    47 ms  ae1-80g.cr1.sfo1.us.nlayer.net [69.22.143.169]
  9    63 ms    60 ms    60 ms  as14061.ae5-401.cr1.sfo1.us.nlayer.net [69.22.13
0.38]
 10    65 ms    66 ms    65 ms  198.199.99.242
 11    67 ms    60 ms    75 ms  proxy1.us.multipool.us [162.243.142.31]

Trace complete.

C:\Users\Administrator>tracert uswest.wafflepool.com

Tracing route to uswest.wafflepool.com [192.241.211.125]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  modem.Home [10.42.0.1]
  2    20 ms    24 ms    20 ms  67.41.239.68
  3    20 ms    20 ms    26 ms  slkc-agw1.inet.qwest.net [67.41.234.25]
  4    38 ms    38 ms    44 ms  snj-edge-03.inet.qwest.net [67.14.34.54]
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *     ^C
C:\Users\Administrator>


Appears to be a major network problem however if multipool hosted on same data centers what gives?

i will try kalroth's cgminer out.  originally when i set this up two weeks ago i was pulling in 2.7Mhs easilly with spikes up to 4.

This is not just a multipool waffle pool attack ALL of my cryptotroll.com pools are reporting 0 shares submitted, restarting cgminer to see if that restores but I doubt it if DDOS

No luck, waffle is not only one under attack.  multipool.us still accepting shares.

I've been waiting for the first real DDOS on wafflepool. Congrats, PW, you've now made the big time!

All joking aside, don't sweat it, it'll get worked out and your hard work is greatly appreciated.

This pool has really come a long way congrats.

EU server not working at this moment for me.

ALL of my pools are reporting 0 shares yet cgminer still submitting shares.

I am using combination of failover and quota for several pools.

EDIT: multipool.us still accepting shares from my miner 3 others not alive

Checked logfile, no redirect shown

Just checked multipool frontend ... new news from them

Mar 23 9:54 PM We are still working to recover all the hot wallets lost in yesterday's hard drive crash. The MOON wallet was unfortunately corrupted, we are currently working to restore it but it may be unrecoverable. Shares for MOON will be saved until the wallet is restored or deemed unrecoverable. The MOON port is back up using a new wallet and working properly

Working on it right now, looks like a DDOS on all of our endpoints.  None of our servers have network connectivity currently.  Contacting support to see whats happening.

Both uswest.wafflepool.com and useast.wafflepool.com are down for me

CGMiner reports all WafflePool servers are down.

@COMEON
This would require co-operation with pool operators and miner devs, fwd your ideas to kalroth gmail and see if he can help implement this new strategy.

Pool is down to 7.16GH/s and my hashrate is almost non-existant.. Did pool crash? I'm on USEast FWIW.

I just rebooted the main miner and it connected to my failover pool.

WafflePool appears to be down.

My 15 minute WafflePool average hash rate is declining while my BAMT rig shows it is going at full speed, is there a pool problem?

As client.reconnect is part of the stratum mining protocol for a reason, and it does have some valid uses, and that removing it is at best a quick hack, the protocol at this point seems to need to be extended so that responsible mining server operators can validate their server identity to mining clients, and public/private key encryption/authentication challenges would be the most readily available and accepted method of accomplishing this goal.  But, discretion should be left to pool operators and not mining clients as to how often authentication challenges occur, so all identity validation transactions should be initiated by the pool, and challenge-enabled clients could participate only if desired, ignore/discard requests if not capable, and not interfere with server operation if the stratum server software is not so equipped, and not be able to warp authentication attempts into any sort of denial of service attack by continually asking the server to authenticate itself.

Mining pool server operators would have to publish their public key, which clients would have to include in their miner configuration files or on the command line, in addition to the usual pool host name, username, and password values.  (Or could optionally choose to exclude public key if they are uninterested in authenticating servers for any reason, and could be enabled on a pool by pool basis in configurations using multiple backup servers.)

The proposed future protocol could look something like this:

mining.subscribe with usual parameters as normal (sent from client)

client.doauthenticate (new) including a randomized request id (sent only from authentication enabled servers, ignored/discarded by already existing and/or incompatible clients)  Upon receipt, client could create a new temporary random public/private key pair if a server public key is included by the user in their pool configuration.

mining.authenticate (new) including that same request id in the clear plus randomized challenge text and client temporary public key both encrypted together with server public key. (sent only by compatible clients, and only in response to client.doauthenticate, should be ignored by servers that did not request an authentication with included request id, should be ignored/discarded by servers that do not support authentication, and never sent by clients respecting the extended protocol unless first requested by server)  Upon receipt, server would decrypt with server private key, extract challenge text and client temporary public key, and reencrypt the decrypted challenge text with client temporary public key)

client.authenticate (new) including that same request id (sent only from authentication enabled servers in response to mining.authenticate, ignored/discarded by already existing and/or incompatible clients)  Upon receipt, client would decrypt with its temporary private key, and validate that the challenge text is the same as sent earlier.

The rest as normal (with authentication enabled clients not receiving authentication waiting for some period before closing the stratum connection and trying again later)

mining.authorize / mining.notify / etc. with all the usual parameters as normal so as to enable any combination of older and newer clients and servers to continue communicating properly with each other.

And every so often the server should send client.doauthenticate messages again, on a schedule as determined by the pool server operator, so as in order to balance server load and efficiency, as often as possible without causing any degradation to the primary purpose of the mining pool server.  If at any point the client cannot authenticate that the server is who is claims to be, it should close the stratum connection, and try to reestablish it again from the very beginning.

At this point, some of you might wish to point out that then your miners will be left sitting idle, but if you have backup servers configured for your miners, authentication for each of them would be performed independently in parallel (at least in cgminer derivatives), and should your primary ever not properly authenticate, but your backup does authenticate, then your miner will start working on the backup pool.

Any suggestions, corrections, and/or glaring omissions on my part?

I also keep going to my failovers. What's going on with wafflepool?

Should I get rid of the "shaders" and "Thread-concurrency" lines in my conf also?

"intensity" : "13,13",
"no-client-reconnect" : true,
"vectors" : "1",
"worksize" : "256",
"kernel" : "scrypt",
"lookup-gap" : "2",
"thread-concurrency" : "11201,8193",
"shaders" : "2048,1792",
"gpu-engine" : "950-1030,1050-1075",
"gpu-fan" : "60-100,60-100",
"gpu-memclock" : "1500,1250",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "1.000-1.081,1.080-1.100",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "69",
"api-mcast-port" : "4028",
"api-port" : "4028",
"auto-fan" : true,
"auto-gpu" : true,
"expiry" : "100",
"load-balance" : true,
"failover-only" : true,
"gpu-dyninterval" : "4",
"gpu-platform" : "0",
"gpu-threads" : "2",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "0",
"scan-time" : "60",
"scrypt" : true,
"temp-hysteresis" : "2",
"shares" : "0",
"kernel-path" : "/usr/local/bin"

Find out how many shaders you have in each card (my 270's have 1280, not sure about the 280 / 7950) and start low with the xintensity (2 or 3) keeping in mind that xintensity is shaders * x. Use the config for both in your cgminer.conf file (IE: "xintensity" : "2,2"). Get cgminer up and running, and then focus on changing the settings for the 280. Keep bumping up the xintensity by 1 until you see a drop-off in your hash rate, go back to the best intensity, then switch to raw intensity.

For my own trial-and-error, I found 3 was the best intensity (1280 * 4 = 3840) then switched to raw intensity and ended up around 4800 (3.75 xintensity).

Remember to set your gpu threads to 2.

Once you've got the 280 running right, then do the same thing for the 7950. I suspect you'll have to start at 1 or 2. I've got no experience with the 7950 so I'm guessing at this point. If you can't use xintensity with the 7950, you can still use intensity, just hit G, then C (change settings) then pick your GPU, then hit I for intensity. Not sure if you can specify both xintensity and intensity in the conf file (it didn't work for me).

Tuning these cards seems to be a combination of blind luck, late nights and the alignment of the stars.

@GMC any advise on the R9-280X and HD7950?
where to start with xintensity (my conf posted a few messages back)
My WUE 91%, Rejects 0.2-0.3%