Bitcoin Forum
December 06, 2016, 07:58:39 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 3160 (80.5%)
Bank transfer / USD - 407 (10.4%)
Gold/silver coins and bars - 359 (9.1%)
Total Voters: 3924

Pages: « 1 ... 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 [870] 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 ... 1105 »
  Print  
Author Topic: [40+ PH] SlushPool (slushpool.com); World's First Mining Pool  (Read 3928263 times)
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
July 26, 2014, 06:02:41 PM
 #17381

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.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481054319
Hero Member
*
Offline Offline

Posts: 1481054319

View Profile Personal Message (Offline)

Ignore
1481054319
Reply with quote  #2

1481054319
Report to moderator
sjc1490
Hero Member
*****
Offline Offline

Activity: 546



View Profile
July 26, 2014, 11:42:06 PM
 #17382

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.

BTC ADDRESS: 12Qwd8VKLQ4xF44ytHXBpCAKuF9VknG4X2
nottm28
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 26, 2014, 11:43:54 PM
 #17383

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.

Thanks for the info eleuthria. So from blockchain.info there is no way (currently) to tell who actually reported the block first?
Any idea when Received time will be fixed or if it is even a priority?

donations not accepted
nottm28
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 26, 2014, 11:46:02 PM
 #17384

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...

donations not accepted
sjc1490
Hero Member
*****
Offline Offline

Activity: 546



View Profile
July 26, 2014, 11:58:59 PM
 #17385

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.

BTC ADDRESS: 12Qwd8VKLQ4xF44ytHXBpCAKuF9VknG4X2
AFlatMinor
Member
**
Offline Offline

Activity: 73


View Profile
July 27, 2014, 12:02:48 AM
 #17386

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

Oh well another long one  Cry

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

Activity: 1988


Ruu \o/


View Profile WWW
July 27, 2014, 04:56:37 AM
 #17387

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
sjc1490
Hero Member
*****
Offline Offline

Activity: 546



View Profile
July 27, 2014, 06:30:28 AM
 #17388

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.

BTC ADDRESS: 12Qwd8VKLQ4xF44ytHXBpCAKuF9VknG4X2
nottm28
Hero Member
*****
Offline Offline

Activity: 574



View Profile
July 27, 2014, 03:00:36 PM
 #17389

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...

donations not accepted
sjc1490
Hero Member
*****
Offline Offline

Activity: 546



View Profile
July 27, 2014, 06:42:01 PM
 #17390

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.

BTC ADDRESS: 12Qwd8VKLQ4xF44ytHXBpCAKuF9VknG4X2
bad1bob
Newbie
*
Offline Offline

Activity: 9


View Profile
July 27, 2014, 07:36:17 PM
 #17391

is BTC any better these invalid blocks are really bullshit
sjc1490
Hero Member
*****
Offline Offline

Activity: 546



View Profile
July 27, 2014, 07:49:31 PM
 #17392

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.

BTC ADDRESS: 12Qwd8VKLQ4xF44ytHXBpCAKuF9VknG4X2
JPoet
Jr. Member
*
Offline Offline

Activity: 59


View Profile
July 27, 2014, 10:41:22 PM
 #17393

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
Full Member
***
Offline Offline

Activity: 154



View Profile
July 27, 2014, 10:43:40 PM
 #17394

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
Jr. Member
*
Offline Offline

Activity: 59


View Profile
July 27, 2014, 11:07:30 PM
 #17395

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

Oh well another long one  Cry

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
Member
**
Offline Offline

Activity: 84


View Profile
July 27, 2014, 11:17:33 PM
 #17396

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
Jr. Member
*
Offline Offline

Activity: 49


View Profile
July 28, 2014, 12:53:26 AM
 #17397

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
Jr. Member
*
Offline Offline

Activity: 59


View Profile
July 28, 2014, 01:38:06 AM
 #17398

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
Jr. Member
*
Offline Offline

Activity: 49


View Profile
July 28, 2014, 02:32:02 AM
 #17399

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
Jr. Member
*
Offline Offline

Activity: 49


View Profile
July 28, 2014, 02:52:36 AM
 #17400

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 :-)
Pages: « 1 ... 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 [870] 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 ... 1105 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!