Just thinking about it, who has experience with vertcoin here? I was thinking whats the MH/BTC/ Profit ratio with this? say you want to chuck 10-14 x R9 290x at it
I am averaging about 0.012BTC/MH/day with vertcoin right now (running 10x R9 290). But that MH value is ~50% of my scrypt(1024,1,1) hashrate. So compared to wafflepool, it would be about .006BTC/MH/day.
Mind you, I'm speculating on vertcoin, so I'm not exchanging immediately.
projectxpps.com is pretty awesome if anyone wants a good vertcoin pool, btw. PPS and 0% fee right now.
Where do you think that client.reconnect command originated anyway? It was not sent by your legitimate stratum servers, that's for sure. And not just anyone can send it, it must arrive on your open stratum connection, or forged to look like it, in order to be processed. Or the attacker must have been able to break your active stratum connection, or wait for it to break naturally, and then redirect you to a rogue server in order to send you that client.reconnect command.
I watched the attack occur and did some analysis (apparently unlike yourself?), and I don't believe there was any prior 'redirect' to a rogue server. My prior comments are more then just speculation... The client.reconnect command appeared to come from the legitimate stratum server. Aka, was "forged to look like it" as you suggest above. I explained above in reasonable detail exactly how such an attack could be potentially replicated. Go try it yourself if you have enough knowledge.
The only other attack method I can imagine based on what I observed, would be TCP injection at (a) key router(s) (by modifying packets and re-calculating header checksums). But, I highly doubt this is the case (else it probably would have been more wide-spread).
I can also assure you that it is still possible at this moment to capture the TCP headers of traffic destined for other servers on OVH right now - more complicated then it was a few months ago since they have been patching their switches, but still possible. The TCP header of course contains the miner IP, port, and current TCP sequence number - which, given the right setup, would be sufficient to counterfeit a packet from the stratum server. You might want to read about TCP injection attacks relating to TCP sequence prediction, if you were not aware this is possible:
http://en.wikipedia.org/wiki/TCP_sequence_prediction_attackFYI: I don't talk about things I am not knowledgeable about. I have nothing to prove (obviously unlike yourself), but I can assure you my knowledge of networking is higher then you might like to believe.
What/where is this patch?
It is not a complete solution, but it does help to a degree, if the next attack mirrors the previous one. Client.reconnect commands were included in the stratum mining protocol for a reason. The 'patch' to which you are referring is built into the latest versions of kalroth cgminer and veox sgminer. Just check their docs for use of no-client-reconnect option. But be forewarned, some pools might legitimately utilize the command, either now or in the future, so to enable it could break certain functionality. But poolwaffle has stated that he does not ever use it, so safe to use here.
It is a complete solution tho... If a pool wants to re-direct my miners somewhere else before the pool goes offline or something, I don't care - that's what fail-overs are for. There is no overly useful case for Client.reconnect that I can imagine. The stratum commands client.reconnect and client.get_version were added to cgminer in v2.8.2, as an aside.
In the copy of sgminer I am running, I simply disabled the client.reconnect ability entirely. Was a 5 second patch.
The reason Slush added client.reconnect to the protocol, btw:
* Implemented method client.reconnect(host, port), so pool can now easily balance clients between backends or gracefully shutdown a backend without a miner outage.
After it was requested by eleuthria:
Please just adopt the two commands I posted about previously: A redirect command for a poolserver to send miners elsewhere, and a server restart notification [with timer] so a pool can attempt a graceful restart rather than suddenly dropping connections.
