ANTMINER S3+ Discussion and Support Thread

[MoreBloodWine]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

[1714705422]

1714705422

[1714705422]

1714705422

[-ck]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

[IYFTech]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

Thanks for confirming ckolivas  

This is why I & others have been making so much noise about this - it's annoying for everyone - but it's for everyones good that it gets fixed ASAP.

Are you listening, Bitmain?

Edit: It is also why miners should only buy hardware that uses Open Source software provided by ckolivas - so that it can be checked for any security issues or "strange goings on" by the cgminer devs or anyone else who wishes to do so. Never buy hardware that uses Closed Source software - there's no way of knowing what it is doing.

[mdude77]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

I assume a properly written proxy could use SSL to secure the connection?

M

[Soros Shorts]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

Would a firewall configuration that only allows tcp/3333 connections to known/whitelisted pool servers help?

[mdude77]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

Would a firewall configuration that only allows tcp/3333 connections to known/whitelisted pool servers help?

No.  The stratum protocol allows redirection.  Unless it's a secure connection, it could be intercepted upstream from you and redirected, and you'd never know the wiser.  That's what the newer cgminer allows (for pools that support it), is using SSL.

M

[-ck]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

Would a firewall configuration that only allows tcp/3333 connections to known/whitelisted pool servers help?

No.  The stratum protocol allows redirection.  Unless it's a secure connection, it could be intercepted upstream from you and redirected, and you'd never know the wiser.  That's what the newer cgminer allows (for pools that support it), is using SSL.

Actually we don't use ssl in cgminer stratum since it's overkill for the actual problem. The problem is a packet is intercepted between you and the pool and it sends back a redirect message to cgminer which consciously moves to the other pool. People who were mining elsewhere unintentionally could actually see their rig had switched. Redirect rules were made strict according to domain name to prevent redirection from happening unless it was to a server with the same domain meaning they'd have to spoof the domain as well. Blocking outgoing connections from cgminer to only selected upstream pools would actually work to prevent you mining elsewhere but you may end up just failing to connect to anything without the redirect protection in later versions.

[edonkey]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

Would a firewall configuration that only allows tcp/3333 connections to known/whitelisted pool servers help?

No.  The stratum protocol allows redirection.  Unless it's a secure connection, it could be intercepted upstream from you and redirected, and you'd never know the wiser.  That's what the newer cgminer allows (for pools that support it), is using SSL.

Actually we don't use ssl in cgminer stratum since it's overkill for the actual problem. The problem is a packet is intercepted between you and the pool and it sends back a redirect message to cgminer which consciously moves to the other pool. People who were mining elsewhere unintentionally could actually see their rig had switched. Redirect rules were made strict according to domain name to prevent redirection from happening unless it was to a server with the same domain meaning they'd have to spoof the domain as well. Blocking outgoing connections from cgminer to only selected upstream pools would actually work to prevent you mining elsewhere but you may end up just failing to connect to anything without the redirect protection in later versions.

You say that SSL is overkill for the problem, and it probably is from a general perspective. But overreaching as it may be it also sounds like SSL would in fact solve this problem, making it impossible for an attacker who does not have access to the SSL keys to send the redirect message in the first place.

Sorry for the off topic post. Maybe there's a better place to discuss this.

[PatMan]

It seems to me that the obvious & right thing for Bitmain to do is what they promised the community they would do. Take down the S3+ firmware update (which does not match the MD5 checksum anyway) and replace it with one that contains the latest cgminer code that fixes the redirect issue. As has been mentioned before - why wouldn't they want to do this? Why would such a large miner manufacturer insist on keeping this security flaw in place?

Food for thought indeed......

[mdude77]

It seems to me that the obvious & right thing for Bitmain to do is what they promised the community they would do. Take down the S3+ firmware update (which does not match the MD5 checksum anyway) and replace it with one that contains the latest cgminer code that fixes the redirect issue. As has been mentioned before - why wouldn't they want to do this? Why would such a large miner manufacturer insist on keeping this security flaw in place?

Food for thought indeed......

I would speculate that they're short staffed, and the oob cgminer doesn't work for them, so they have to customize it.

M

[PatMan]

It seems to me that the obvious & right thing for Bitmain to do is what they promised the community they would do. Take down the S3+ firmware update (which does not match the MD5 checksum anyway) and replace it with one that contains the latest cgminer code that fixes the redirect issue. As has been mentioned before - why wouldn't they want to do this? Why would such a large miner manufacturer insist on keeping this security flaw in place?

Food for thought indeed......

I would speculate that they're short staffed, and the oob cgminer doesn't work for them, so they have to customize it.

M

I just can't see that being the case tbh. I'm sure if they found their entire hashing farm was being redirected to a different pool, they'd soon implement it.......

[ftoole]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

Would a firewall configuration that only allows tcp/3333 connections to known/whitelisted pool servers help?

No.  The stratum protocol allows redirection.  Unless it's a secure connection, it could be intercepted upstream from you and redirected, and you'd never know the wiser.  That's what the newer cgminer allows (for pools that support it), is using SSL.

M

The reason its smart to have each miner on its own worker and then have a pool that will e-mail you when your workers have been idle.

[PatMan]

As long as someone doesnt know the IP of the given miner you should be "safe" right ?

No. The attack occurred upstream, between the miner and the pool.

Would a firewall configuration that only allows tcp/3333 connections to known/whitelisted pool servers help?

No.  The stratum protocol allows redirection.  Unless it's a secure connection, it could be intercepted upstream from you and redirected, and you'd never know the wiser.  That's what the newer cgminer allows (for pools that support it), is using SSL.

M

The reason its smart to have each miner on its own worker and then have a pool that will e-mail you when your workers have been idle.

I don't believe that to be the case I'm afraid. I believe it's possible to redirect a proportion of hash rate, so that your miners never actually show as idle......not sure though, maybe ckolivas can clarify this?

[valkyrie69]

Hi guys,

I just got started with my first Antminer S3 and one of the features I liked the look of was the ability to specify three pools and mine from them simultaneously. I figured that this would mean a more stable level of mining income for me since using three pools would mean that the risk of one pool being very unlucky in any given time period would be offset by the chance of one of the other two pools being above average lucky. All things being equal, it should mean getting closer to a miner's average return, rather than peaks and troughs. At least that was the theory...

When I tried this, I initially set it up with Ghash.io, Slush and BTC Guild. All was good except that GHash error rate decided to go to the moon! I started getting 60 - 80% reject rates per shift with masses of low difficulty rejects, despite specifying in their workers page to send them at diff 256. This was in stark contrast to when I first rigged it up online. I pointed it at Ghash.io alone and it performed very well, a few GH/s less than advertised but I'm only running it off of a CS550M PSU with two connectors so I hadn't expected it to overperform.

Naturally I did what any sane miner would do and ditched GHash.io in favour of Eligius  

Jokes aside, does the S3 perform as rewardingly when split between 3 pools as it does when aimed just at 1 or does some GH/s never get utilized? And does anyone know why mine struggles with GHash.io difficulty when it's aimed there as part of a balanced pool set up but works fine with GHash.io if I set it to work 100% on that pool alone?

PS Sorry to post this while an important discussion on security is going on but I wasn't sure whether to start a new thread for this or keep it in this thread where all the S3 expertise is clearly hanging out 

[Pt0x]

Maybe @Kano could come to the rescue and compile a new binary just like he did with the s1/s2?

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

I´m even willing to send him a tip, anyone else cares to join?

[Biodom]

Hi guys,

I just got started with my first Antminer S3 and one of the features I liked the look of was the ability to specify three pools and mine from them simultaneously. I figured that this would mean a more stable level of mining income for me since using three pools would mean that the risk of one pool being very unlucky in any given time period would be offset by the chance of one of the other two pools being above average lucky. All things being equal, it should mean getting closer to a miner's average return, rather than peaks and troughs. At least that was the theory...

When I tried this, I initially set it up with Ghash.io, Slush and BTC Guild. All was good except that GHash error rate decided to go to the moon! I started getting 60 - 80% reject rates per shift with masses of low difficulty rejects, despite specifying in their workers page to send them at diff 256. This was in stark contrast to when I first rigged it up online. I pointed it at Ghash.io alone and it performed very well, a few GH/s less than advertised but I'm only running it off of a CS550M PSU with two connectors so I hadn't expected it to overperform.

Naturally I did what any sane miner would do and ditched GHash.io in favour of Eligius  

Jokes aside, does the S3 perform as rewardingly when split between 3 pools as it does when aimed just at 1 or does some GH/s never get utilized? And does anyone know why mine struggles with GHash.io difficulty when it's aimed there as part of a balanced pool set up but works fine with GHash.io if I set it to work 100% on that pool alone?

PS Sorry to post this while an important discussion on security is going on but I wasn't sure whether to start a new thread for this or keep it in this thread where all the S3 expertise is clearly hanging out  

the purpose of three pools specification usually is NOT to split equally, but to provide a backup. BTW, you don't have to have a third pool specified, it could be just two.

[miguportugal]

hello

did anyone test the last firmware antMiner_S320140826.bin?

what gains can we achieve with this new firmwere?

[valkyrie69]

Hi guys,

I just got started with my first Antminer S3 and one of the features I liked the look of was the ability to specify three pools and mine from them simultaneously. I figured that this would mean a more stable level of mining income for me since using three pools would mean that the risk of one pool being very unlucky in any given time period would be offset by the chance of one of the other two pools being above average lucky. All things being equal, it should mean getting closer to a miner's average return, rather than peaks and troughs. At least that was the theory...

When I tried this, I initially set it up with Ghash.io, Slush and BTC Guild. All was good except that GHash error rate decided to go to the moon! I started getting 60 - 80% reject rates per shift with masses of low difficulty rejects, despite specifying in their workers page to send them at diff 256. This was in stark contrast to when I first rigged it up online. I pointed it at Ghash.io alone and it performed very well, a few GH/s less than advertised but I'm only running it off of a CS550M PSU with two connectors so I hadn't expected it to overperform.

Naturally I did what any sane miner would do and ditched GHash.io in favour of Eligius  

Jokes aside, does the S3 perform as rewardingly when split between 3 pools as it does when aimed just at 1 or does some GH/s never get utilized? And does anyone know why mine struggles with GHash.io difficulty when it's aimed there as part of a balanced pool set up but works fine with GHash.io if I set it to work 100% on that pool alone?

PS Sorry to post this while an important discussion on security is going on but I wasn't sure whether to start a new thread for this or keep it in this thread where all the S3 expertise is clearly hanging out  

the purpose of three pools specification usually is NOT to split equally, but to provide a backup. BTW, you don't have to have a third pool specified, it could be just two.

Yes, I am aware I can have 1, 2 or 3 pools. My view is that since BTC Guild, Eligius and Slush combined are equal to a little less than GHash.io or Discus Fish in terms of hashing power, by mining on all three I should get a similar rate of payout to if I were on one of the big two (although I won't get to payout thresholds as quickly). I prefer this because although I'm only a tiny fish in a big ocean, I'd like bitcoin to stay decentralised and because it gives me a smoother payout rate rather than the lumpy mining that comes from putting all my hashing power on one smaller pool. A steadier payout rate means I can use my BTC for everyday purchases more easily rather than being a hoarding or trading type that is concerned with BTC's value in fiat. In short, for me it's an extra income. But that's just my philosophy. What I'm really looking for is someone who knows whether an S3 running in balance mode delivers it's full GH/s and why balance and load balance mode seem to cause trouble with Ghash.io difficulty settings.

[-ck]

Maybe @Kano could come to the rescue and compile a new binary just like he did with the s1/s2?

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

I´m even willing to send him a tip, anyone else cares to join?

I'll look at the code today.

[Biodom]

Hi guys,

I just got started with my first Antminer S3 and one of the features I liked the look of was the ability to specify three pools and mine from them simultaneously. I figured that this would mean a more stable level of mining income for me since using three pools would mean that the risk of one pool being very unlucky in any given time period would be offset by the chance of one of the other two pools being above average lucky. All things being equal, it should mean getting closer to a miner's average return, rather than peaks and troughs. At least that was the theory...

When I tried this, I initially set it up with Ghash.io, Slush and BTC Guild. All was good except that GHash error rate decided to go to the moon! I started getting 60 - 80% reject rates per shift with masses of low difficulty rejects, despite specifying in their workers page to send them at diff 256. This was in stark contrast to when I first rigged it up online. I pointed it at Ghash.io alone and it performed very well, a few GH/s less than advertised but I'm only running it off of a CS550M PSU with two connectors so I hadn't expected it to overperform.

Naturally I did what any sane miner would do and ditched GHash.io in favour of Eligius  

Jokes aside, does the S3 perform as rewardingly when split between 3 pools as it does when aimed just at 1 or does some GH/s never get utilized? And does anyone know why mine struggles with GHash.io difficulty when it's aimed there as part of a balanced pool set up but works fine with GHash.io if I set it to work 100% on that pool alone?

PS Sorry to post this while an important discussion on security is going on but I wasn't sure whether to start a new thread for this or keep it in this thread where all the S3 expertise is clearly hanging out  

the purpose of three pools specification usually is NOT to split equally, but to provide a backup. BTW, you don't have to have a third pool specified, it could be just two.

Yes, I am aware I can have 1, 2 or 3 pools. My view is that since BTC Guild, Eligius and Slush combined are equal to a little less than GHash.io or Discus Fish in terms of hashing power, by mining on all three I should get a similar rate of payout to if I were on one of the big two (although I won't get to payout thresholds as quickly). I prefer this because although I'm only a tiny fish in a big ocean, I'd like bitcoin to stay decentralised and because it gives me a smoother payout rate rather than the lumpy mining that comes from putting all my hashing power on one smaller pool. A steadier payout rate means I can use my BTC for everyday purchases more easily rather than being a hoarding or trading type that is concerned with BTC's value in fiat. In short, for me it's an extra income. But that's just my philosophy. What I'm really looking for is someone who knows whether an S3 running in balance mode delivers it's full GH/s and why balance and load balance mode seem to cause trouble with Ghash.io difficulty settings.

at some pools (Slush's) you can select the payout at as low as 0.001 BTC; you can also point several miners to the same wallet address (in Eligius, just use <wallet address>_<name of the miner>), which will speed up the payouts.