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

[sjc1490]

Anyone who recently put S3's on here needs to check out https://bitcointalk.org/index.php?topic=671189.msg8041024#msg8041024 if they haven't seen the post on how to reduce all the discarded shares. Simple as ssh into the miner and adding/changing parameters to line 75 of cgminer file. dropped mine easily 10x.

I don't have any S3's yet but have some on order - but those who do might also read this...

https://bitcointalk.org/index.php?topic=699064.msg8042352#msg8042352

[edit] could just be a lucky miner but worth a try...

Hopefully on the later batch you will have better luck I was early B1. I have one runs around 230's and the other 240's @218.75 with the 2 or 4 connectors. I have been keeping up with the S3 post and I agree and would try all suggestions as it appears there is a wide variation in how these things respond to the various changes.

[1714160483]

1714160483

[1714160483]

1714160483

[1714160483]

1714160483

[AFlatMinor]

looks like we made it through.  good luck for a better day.

Oh well another long one  

For those who might like to know this is the only 2 consecutive +10 hour blocks in the last 250 blocks (39 days)

[-ck]

Anyone who recently put S3's on here needs to check out https://bitcointalk.org/index.php?topic=671189.msg8041024#msg8041024 if they haven't seen the post on how to reduce all the discarded shares. Simple as ssh into the miner and adding/changing parameters to line 75 of cgminer file. dropped mine easily 10x.

That's bad advice. Please read my followup on that thread.

[sjc1490]

Anyone who recently put S3's on here needs to check out https://bitcointalk.org/index.php?topic=671189.msg8041024#msg8041024 if they haven't seen the post on how to reduce all the discarded shares. Simple as ssh into the miner and adding/changing parameters to line 75 of cgminer file. dropped mine easily 10x.

That's bad advice. Please read my followup on that thread.

Thanks I totally missed your post advising against it. I have to say though it has done nothing but enhance both miners performance. Load is down, disregards are down 10x, bestshare is a lot higher on both. I am not understanding what the detriment you refer to, is could you help out by explaining? Thanks again.

I would also suggest repost your warning in the S3 thread with a more in depth explanation of the hazards as it comes back up every 3 or 4 pages with a whole new group of people doing the mod.

[nottm28]

Another orphan block 312664

http://blockchain.info/block/00000000000000002abbf0d2df6840533f90bc5d45c115a9cf6e0f3f99feb84d?site=slush

That's an unusally high rate of orphans for this pool - come on slush sort it out - looks like something is wrong...

[sjc1490]

Another orphan block 312664

http://blockchain.info/block/00000000000000002abbf0d2df6840533f90bc5d45c115a9cf6e0f3f99feb84d?site=slush

That's an unusally high rate of orphans for this pool - come on slush sort it out - looks like something is wrong...

I have only been here since March and correct me if wrong but over the last 2 weeks there has been more orphaned blocks than I remember seeing the entire time previous to then.  Over 12 hours wasted time in 3 days.

[bad1bob]

is BTC any better these invalid blocks are really bullshit

[sjc1490]

I don't understand how bitminter can win block 312400 and our find becomes orphaned.

Slush reported 312400 at

2014-07-25 09:02:11

Bitminter reported 312400 at

2014-07-25 09:02:58

That's 47 seconds later than us. I can understand if the time between two pools finding the same block is very short, but 47 seconds?

https://blockchain.info/block-height/312400

Block timestamps should not be considered the actual times they were made.  The timestamp for the block is part of your header data before you start hashing it, and is based off the pool server's clock.  It also doesn't have to be updated as you continue to hash.  Blockchain.info used to have 'Received time' vs 'Timestamp', but for the last few months that has been broken and they just use the timestamp for both.

I don't know about them but reading a previous post on the matter I would research any pool you are thinking about switching to as this could be effecting more than us. All I know is it sucks.

[JPoet]

I like it, it works fine. Reliable and steady.
S3 can get the same GH/s for about 2/3 the cost, and I am just tired of $600 plus electric bills.
The S2 is a fine 55nm miner, I just want to migrate to 28nm.

seems like bitmain may have discontinued the S2.  thinking about pulling the trigger on a few s3's.  this may be an addiction, or 21st century mid life crisis:)

[psahx]

I don't understand how bitminter can win block 312400 and our find becomes orphaned.

Slush reported 312400 at

2014-07-25 09:02:11

Bitminter reported 312400 at

2014-07-25 09:02:58

That's 47 seconds later than us. I can understand if the time between two pools finding the same block is very short, but 47 seconds?

https://blockchain.info/block-height/312400

Block timestamps should not be considered the actual times they were made.  The timestamp for the block is part of your header data before you start hashing it, and is based off the pool server's clock.  It also doesn't have to be updated as you continue to hash.  Blockchain.info used to have 'Received time' vs 'Timestamp', but for the last few months that has been broken and they just use the timestamp for both.

I don't know about them but reading a previous post on the matter I would research any pool you are thinking about switching to as this could be effecting more than us. All I know is it sucks.

Come to BTCGuild. Orphan rate is less then 0.01%

[JPoet]

looks like we made it through.  good luck for a better day.

Oh well another long one  

For those who might like to know this is the only 2 consecutive +10 hour blocks in the last 250 blocks (39 days)

looks like I missed the good times. 

[Donkeycongo]

I don't understand how bitminter can win block 312400 and our find becomes orphaned.

Slush reported 312400 at

2014-07-25 09:02:11

Bitminter reported 312400 at

2014-07-25 09:02:58

That's 47 seconds later than us. I can understand if the time between two pools finding the same block is very short, but 47 seconds?

https://blockchain.info/block-height/312400

Block timestamps should not be considered the actual times they were made.  The timestamp for the block is part of your header data before you start hashing it, and is based off the pool server's clock.  It also doesn't have to be updated as you continue to hash.  Blockchain.info used to have 'Received time' vs 'Timestamp', but for the last few months that has been broken and they just use the timestamp for both.

I don't know about them but reading a previous post on the matter I would research any pool you are thinking about switching to as this could be effecting more than us. All I know is it sucks.

Come to BTCGuild. Orphan rate is less then 0.01%

We haven't had that many invalids this year, just had a few of late. It has nothing to do with the pools functionality.

[dbbrummel]

The 12 hour and invalid blocks are a test.
They tempt you go elsewhere, hoping you
will do better.

There is no pool, anywhere, that has all
good days. Math just does not work that
way.

[JPoet]

The 12 hour and invalid blocks are a test.
They tempt you go elsewhere, hoping you
will do better.

There is no pool, anywhere, that has all
good days. Math just does not work that
way.

well if that was true wwii would have ended differently.  don't confuse luck as in slot machines with math.  if math worked this way we would never have put a man on the moon in the 60's.

[dbbrummel]

The 12 hour and invalid blocks are a test.
They tempt you go elsewhere, hoping you
will do better.

There is no pool, anywhere, that has all
good days. Math just does not work that
way.

well if that was true wwii would have ended differently.  don't confuse luck as in slot machines with math.  if math worked this way we would never have put a man on the moon in the 60's.

There are different kinds of math. Probability and Algebra live in different worlds.

Algebra puts men on the moon, Probability wins the lottery. Sometimes.

[dbbrummel]

For my brethren still waiting on their S3 7.7% refunds:

----------------------
Hi,

Engineer is processing refund one by one, and they said will finish all refund the the end of 12pm July 28 Beijing time

Best Regards

BITMAIN

----------------------
Pure Chinglish, so you know it is real :-)

[kkurtmann]

It is nice that much hashing power left the pool near the end of that last 12 hour block, got much larger payout. Thanks for bailing guys.

[Donkeycongo]

The 12 hour and invalid blocks are a test.
They tempt you go elsewhere, hoping you
will do better.

There is no pool, anywhere, that has all
good days. Math just does not work that
way.

well if that was true wwii would have ended differently.  don't confuse luck as in slot machines with math.  if math worked this way we would never have put a man on the moon in the 60's.

There are different kinds of math. Probability and Algebra live in different worlds.

Algebra puts men on the moon, Probability wins the lottery. Sometimes.

Probability is a form of calculable math, when working with probability algebra is often used to display a formula.

Probability wins blackjack, luck wins lottery.

[dbbrummel]

The 12 hour and invalid blocks are a test.
They tempt you go elsewhere, hoping you
will do better.

There is no pool, anywhere, that has all
good days. Math just does not work that
way.

well if that was true wwii would have ended differently.  don't confuse luck as in slot machines with math.  if math worked this way we would never have put a man on the moon in the 60's.

There are different kinds of math. Probability and Algebra live in different worlds.

Algebra puts men on the moon, Probability wins the lottery. Sometimes.

Probability is a form of calculable math, when working with probability algebra is often used to display a formula.

Probability wins blackjack, luck wins lottery.

Sounds like you know math better than me, I was a Philosophy major.
Does it change anything in regards to pool  hopping?

[Donkeycongo]

The 12 hour and invalid blocks are a test.
They tempt you go elsewhere, hoping you
will do better.

There is no pool, anywhere, that has all
good days. Math just does not work that
way.

well if that was true wwii would have ended differently.  don't confuse luck as in slot machines with math.  if math worked this way we would never have put a man on the moon in the 60's.

There are different kinds of math. Probability and Algebra live in different worlds.

Algebra puts men on the moon, Probability wins the lottery. Sometimes.

Probability is a form of calculable math, when working with probability algebra is often used to display a formula.

Probability wins blackjack, luck wins lottery.

Sounds like you know math better than me, I was a Philosophy major.
Does it change anything in regards to pool  hopping?

You could do a probability on pool luck based on all the previous rounds, but solving a block comes down to luck > hash power, not very accurate unlike with counting cards which has a set amount of variables each hand, vardiff is suppose to stop pool hopping, I reckon there would be people out there jumping onto pools at near end of round, to make that work it would be a full time job. There really is no predictable end to a round.