[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[sandos]

Hi, I'm connecting to the pool through Tor.  What's to stop a tor exit node sniffing my data, and claiming my shares for itself?  Can the bitcoin getwork() interface be encrypted?  Just to let you know, it hasn't happened yet I think.  I did lose one share yesterday, but it might be network latency.

You'd have to be really unlucky, it would be more lucrative to just replace all ads on the Webpages you visit with it's own
The Tor Proxy would have to be custom coded to intercept your pool communication and we're far from being big enough for it to pay for the hack.

Tor requires end-to-end encryption to be safe against eavesdropping, and thats nothing new.

[Cdecker]

There's an idea: offer your pool over Tor
Would be a nice alternative to using Tor exit nodes and would reduce latency (bigger choice of intermediate nodes) ^^

[slush]

Using pool over Tor is nonsense, your rountrip will be much higher, so you hit stale blocks more often. I'm running some Tor relays so I have quite knowledge about latencies .

About stealing shares - it's not possible. Share is valid only for your worker.

[fergalish]

About stealing shares - it's not possible. Share is valid only for your worker.

Can you explain more?  I realise that an attack is very unlikely, but I'm curious.  Do you keep a record of which work has been assigned to which worker?  Everything else is the same - the data, the target etc.  Only the work (nonce? is that what it's called?) changes, so it would be enough for an evil tor exit node to connect to the pool with it's own worker credentials and submit my successful nonce.

Using pool over Tor is nonsense

Unfortunately, there is a firewall here, so I have to use tor to connect, unless you can open a port<1024 and forward to 8332 on your machine.  So far latencies don't seem to be causing any problem.  I reduced the ask rate to every 10sec, so it pauses less often.  I'd experiment to find the best values, but I only ever expect to earn about 80BTC through generation, so I'm not very motivated.

[slush]

Do you keep a record of which work has been assigned to which worker?

Yes.

Only the work (nonce? is that what it's called?) changes,

'Nonce' is 32bit number, which every miner iterate over to find a valid share. Nonce is valid only for given job, which is bounded to specific worker. So malicious Tor exit cannot pick your share and submit it as own. He can only corrupt/refuse the submit request or so.

I reduced the ask rate to every 10sec, so it pauses less often.

With rising ask rate you have bigger chance to hit stall share. That means, if you get work from pool and then new bitcoin block is found, your submit from this share will be invalid. With 10sec ask rate and Tor latencies, you are on ~15 second delay. Bitcoin block is found in average every 600 seconds (practically it is less, because Bitcoin network is growing rapidly), so your average overhead is 15/600 = 2.5%. So 2.5% of your hashing power is wasted. Not an extreme, but you have to count with it.

[fergalish]

So 2.5% of your hashing power is wasted. Not an extreme, but you have to count with it.

I'm using m0mchil's python miner, and everytime it submits a getwork request, it stops hashing, opens the connection, gets the work, and then starts again.  This causes me to lose much more that 2.5% of my hashing power, more like 15% or so (note, that's hashing power, not hashes).  Like I say, if I were worried I'd modify the miner, but between now and when the sun goes out, I can only expect another 70 or 80 bitcoins with my meager 20Mhps if the bitcoin network keeps growing as it is for a while longer.  So it'll do as it is.  Thanks for the reply.

[m0mchil]

I'm using m0mchil's python miner, and everytime it submits a getwork request, it stops hashing, opens the connection, gets the work, and then starts again.

With which version? POCLBM uses separate IO thread since 18 December, around first appearance of the pool. It however sets maximum socket timeout to 5 seconds, everything above that would result in old jobs anyway.

[slush]

more like 15% or so (note, that's hashing power, not hashes). 

Looks weird. How is you network going? Any packet losses, timeouts?

[gusti]

Does "Your Daily Reward" Graph stands for Total Reward, or only Confirmed Reward ?

[slush]

Does "Your Daily Reward" Graph stands for Total Reward, or only Confirmed Reward ?

It's calculated from all found blocks in this day, so total reward. And yes, yesterday was not good, but it is how it works. Two days before were fine, for example.

[slush]

I had to perform full server restart. I'm sorry for short outage. This is also first restart for more than month where many stability patches in miners were included. So I'm wondering if anybody had problem with reconnecting his miners back to restarted pool. If so, please post errors/tracebacks here...

[gusti]

No problem with restart, but maybe will be good to receive an email with at least 6 hrs in advance.

[antz123]

Just checked online and my miners are still running, I assume they restarted themselves when the server was back up.

Did it go down last night? My miners stopped running for a while and I kept getting 502's when trying to load up the site.

[slush]

Just checked online and my miners are still running, I assume they restarted themselves when the server was back up.
Did it go down last night? My miners stopped running for a while and I kept getting 502's when trying to load up the site.

Yes, I did mistake in network configuration, so there was small outage, too. But it was not full restart with all stuff bootstrapping.

[gusti]

Please advice at what UTC time you are planning the reboot, so I will be watching accordingly.

[slush]

Please advice at what UTC time you are planning the reboot, so I will be watching accordingly.

Tell me your phone, I'll call you!

This reboot was unplanned outage, so sorry, I cannot tell you 6 hours before in this case.

[gusti]

Sorry, I misunderstood, I thought that new reboot was coming.
Anyway, the email advice would be nice. 

[slush]

Sorry, I misunderstood, I thought that new reboot was coming.
Anyway, the email advice would be nice. 

I have email notification about crashed miners almost done for many weeks. Unfortunately bad guys are inventing more and more bad things, which makes me busy on fixing it

[BitLex]

i really dislike your decision to remove all the useful stats and only keep those that don't really matter to me anyways.

it doesn't matter how many blocks my workers found, won't get me anything more or less if they found a lot or none,
but what i want to know is the number of shares that a given worker got, makes tweaking and debugging a lot easier.

right now i can't tell which worker (or miner-version) is performing good or bad.

[gusti]

i really dislike your decision to remove all the useful stats and only keep those that don't really matter to me anyways.

it doesn't matter how many blocks my workers found, won't get me anything more or less if they found a lot or none,
but what i want to know is the number of shares that a given worker got, makes tweaking and debugging a lot easier.

right now i can't tell which worker (or miner-version) is performing good or bad.

Well, I believe that you may count them on your side, too.
But I also think that stats were useful, I think Slush needed to take them out due to pooling cheating.