Bitcoin Forum
April 27, 2024, 12:15:59 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 [779] 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 ... 1154 »
  Print  
Author Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool  (Read 4381856 times)
KNK
Hero Member
*****
Offline Offline

Activity: 692
Merit: 502


View Profile
March 01, 2014, 10:32:20 AM
 #15561

My apologies KNK, It appears I may have spoken to soon. (Technically that first block was pretty well past the 2h 15min mark )
But you nailed the turn in luck prediction Smiley
No, I made 2 mistakes in that prediction, so I was wrong, but yes, the luck had to turn up at 20%

finally ty for whoever did some magic for better luck

There is no magic, it was expected, because the luck should average at 100% - when it's too low it should go up

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
1714220159
Hero Member
*
Offline Offline

Posts: 1714220159

View Profile Personal Message (Offline)

Ignore
1714220159
Reply with quote  #2

1714220159
Report to moderator
1714220159
Hero Member
*
Offline Offline

Posts: 1714220159

View Profile Personal Message (Offline)

Ignore
1714220159
Reply with quote  #2

1714220159
Report to moderator
Activity + Trust + Earned Merit == The Most Recognized Users on Bitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
nukka33
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
March 01, 2014, 02:20:24 PM
 #15562

My apologies KNK, It appears I may have spoken to soon. (Technically that first block was pretty well past the 2h 15min mark )
But you nailed the turn in luck prediction Smiley
No, I made 2 mistakes in that prediction, so I was wrong, but yes, the luck had to turn up at 20%

finally ty for whoever did some magic for better luck

There is no magic, it was expected, because the luck should average at 100% - when it's too low it should go up


the mining is becoming a bit boring tho... (even on slush's - mining on btcguild and ghash is always boring...)

those were the days when we were finding 10 blocks a day (on average) - and that was at the beginning of january!

now - all there's left is watching the double digits going up... and up...Sad


still - it was exciting last night for about an hour...Wink

necro_nemesis
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
March 01, 2014, 02:26:17 PM
 #15563

Yeah it's really exciting watching a stock market predictability decline at an unpredictable rate.   Undecided
nukka33
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
March 01, 2014, 02:46:07 PM
 #15564

Yeah it's really exciting watching a stock market predictability decline at an unpredictable rate.   Undecided

i was talking about our 3 blocks found in 61 minutes...
necro_nemesis
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
March 01, 2014, 02:53:31 PM
 #15565

Yeah it's really exciting watching a stock market predictability decline at an unpredictable rate.   Undecided

i was talking about our 3 blocks found in 61 minutes...

Understood, and I referring to days of 12hr blocks. Paint does dry faster.
nukka33
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
March 01, 2014, 03:03:11 PM
 #15566

Yeah it's really exciting watching a stock market predictability decline at an unpredictable rate.   Undecided

i was talking about our 3 blocks found in 61 minutes...

Understood, and I referring to days of 12hr blocks. Paint does dry faster.


12 hrs is (as we are slowly finding out) not that long...Wink

Searing
Copper Member
Legendary
*
Offline Offline

Activity: 2898
Merit: 1464


Clueless!


View Profile
March 01, 2014, 03:05:24 PM
 #15567

Yeah it's really exciting watching a stock market predictability decline at an unpredictable rate.   Undecided

i was talking about our 3 blocks found in 61 minutes...

Understood, and I referring to days of 12hr blocks. Paint does dry faster.


12 hrs is (as we are slowly finding out) not that long...Wink



the ways of slush's luck/blocks etc are mysterious to me!

(must also take up paint drying as another hobby then watching slush pool via ssh and my knc miner...eureka maybe paint my room and watch slush feed
it would still suck but at least I'd be multitasking)

man I need a life....of course it is Friday nite in Minnesota and 30 below wind chill could be worse

Searing

Old Style Legacy Plug & Play BBS System. Get it from www.synchro.net. Updated 1/1/2021. It also works with Windows 10 and likely 11 and allows 16 bit DOS game doors on the same Win 10 Machine in Multi-Node! Five Minute Install! Look it over it uninstalls just as fast, if you simply want to look it over. Freeware! Full BBS System! It is a frigging hoot!:)
necro_nemesis
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
March 01, 2014, 03:15:21 PM
 #15568

This is good news. Difficulty may drop from sheer mining boredom.
nukka33
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
March 01, 2014, 04:13:54 PM
 #15569

This is good news. Difficulty may drop from sheer mining boredom.

we can only hope...
kkurtmann
Sr. Member
****
Offline Offline

Activity: 475
Merit: 250



View Profile WWW
March 01, 2014, 07:02:31 PM
 #15570

If the blame lies anywhere, it's in me being a poor teacher.
No, it's more to do with somebody being a very slow learner.

Quote
I should probably write up something permanent somewhere that just addresses pool luck, and that people can link to whenever luck gets raised.
They won't read it; or if they do, they either won't understand it, or refuse to accept it because you don't support their own arguments.

+1

https://www.buytrezor.com?a=55c37b866c11   well sir, I like it!
gourmet
Sr. Member
****
Offline Offline

Activity: 311
Merit: 250


View Profile
March 01, 2014, 10:56:30 PM
 #15571

Holy crap - a 35 second block - that has to be some kind of record!

naw, i saw a 20 second block once.

I remember a 14 second one. And it's not been too long ago.
And a 4 second one last year.
nottm28
Hero Member
*****
Offline Offline

Activity: 574
Merit: 500



View Profile
March 01, 2014, 11:17:31 PM
 #15572

Holy crap - a 35 second block - that has to be some kind of record!

naw, i saw a 20 second block once.

I remember a 14 second one. And it's not been too long ago.
And a 4 second one last year.

Shortest I ever seen was block 239570 found by slush on 2013-06-03 in just 2 seconds. Unfortunately it was invalid for us...


donations not accepted
EdB666
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
March 01, 2014, 11:33:28 PM
 #15573

Holy crap - a 35 second block - that has to be some kind of record!

naw, i saw a 20 second block once.

I remember a 14 second one. And it's not been too long ago.
And a 4 second one last year.

Shortest I ever seen was block 239570 found by slush on 2013-06-03 in just 2 seconds. Unfortunately it was invalid for us...



I guess there must be some minimum amount of time for a block to be seen by the network before the next block can be found?
nottm28
Hero Member
*****
Offline Offline

Activity: 574
Merit: 500



View Profile
March 01, 2014, 11:42:14 PM
 #15574

Holy crap - a 35 second block - that has to be some kind of record!

naw, i saw a 20 second block once.

I remember a 14 second one. And it's not been too long ago.
And a 4 second one last year.

Shortest I ever seen was block 239570 found by slush on 2013-06-03 in just 2 seconds. Unfortunately it was invalid for us...



I guess there must be some minimum amount of time for a block to be seen by the network before the next block can be found?

I'm not sure about a minimum time, it was just that another pool found the same 2 second block and reported it to the network before we did.

donations not accepted
EdB666
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
March 02, 2014, 12:16:50 AM
 #15575

Holy crap - a 35 second block - that has to be some kind of record!

naw, i saw a 20 second block once.

I remember a 14 second one. And it's not been too long ago.
And a 4 second one last year.

Shortest I ever seen was block 239570 found by slush on 2013-06-03 in just 2 seconds. Unfortunately it was invalid for us...



I guess there must be some minimum amount of time for a block to be seen by the network before the next block can be found?

I'm not sure about a minimum time, it was just that another pool found the same 2 second block and reported it to the network before we did.

My understanding is that when two pools find the 'same' block, they are actually finding different hashes that meet the difficulty requirement (please correct me if I am wrong). In this case, given that the network difficulty makes this so that the expected block length is ten minutes, and invalid blocks are not that common (IIRC, we have seen two in the last month or so), I am quite surprised that there should be such a 'collision' on a two-second block - surely the odds of this happening would be vanishingly small, unless there is something intrinsic that makes the difficulty on certain blocks much lower than it should be.
J_Dubbs
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250



View Profile
March 02, 2014, 02:48:16 AM
 #15576

Few weeks ago, maybe even a whole month, there was an announcement about the server jamming up just shy of 900th.
You will keep repeating that until you start to believe it ... OK go on I can ignore it the way you ignored my replies pointing the opposite

Perhaps I should apologize, it was an oversight on my part if I ignored a response. I do recall a solid explanation was posted some time ago, not sure if by you or someone else, but I may have been hasty in fully understanding it, or perhaps I understood and grew skeptical over time seeing events that appear to be related. I am eager to learn and understand about the existing logical explanation, but I also like to keep an open mind, and I have a tendency due to my right-brain thinking preference to build heuristics for incomplete models rather than understand algorithms or detailed lists. Would you be so kind to post it again or provide the link so I can take another look?
gourmet
Sr. Member
****
Offline Offline

Activity: 311
Merit: 250


View Profile
March 02, 2014, 06:12:19 AM
Last edit: March 02, 2014, 08:03:24 AM by gourmet
 #15577

My understanding is that when two pools find the 'same' block, they are actually finding different hashes that meet the difficulty requirement (please correct me if I am wrong). In this case, given that the network difficulty makes this so that the expected block length is ten minutes, and invalid blocks are not that common (IIRC, we have seen two in the last month or so), I am quite surprised that there should be such a 'collision' on a two-second block - surely the odds of this happening would be vanishingly small, unless there is something intrinsic that makes the difficulty on certain blocks much lower than it should be.

Not only different hashes; each pool assembles its own block from the available transactions in the transaction pool according to its rules. So the "same" block can potentially differ between the two pools in the sense it contains different transactions.

The last idea is quite interesting. Can someone have enough will and power to check it? :-)
[edit] I'd sure not say vanishingly, but the chance is of course smaller for two pools at once than it is for one pool.
EdB666
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
March 02, 2014, 11:24:05 AM
 #15578

My understanding is that when two pools find the 'same' block, they are actually finding different hashes that meet the difficulty requirement (please correct me if I am wrong). In this case, given that the network difficulty makes this so that the expected block length is ten minutes, and invalid blocks are not that common (IIRC, we have seen two in the last month or so), I am quite surprised that there should be such a 'collision' on a two-second block - surely the odds of this happening would be vanishingly small, unless there is something intrinsic that makes the difficulty on certain blocks much lower than it should be.

Not only different hashes; each pool assembles its own block from the available transactions in the transaction pool according to its rules. So the "same" block can potentially differ between the two pools in the sense it contains different transactions.

The last idea is quite interesting. Can someone have enough will and power to check it? :-)
[edit] I'd sure not say vanishingly, but the chance is of course smaller for two pools at once than it is for one pool.

I would have thought that the probability of two people finding a sub 2-second block, at the same time would be the probability of one finding it, squared.
Assuming the block difficulty is correct, at the moment, we are on block 288579. 
I don't know how many 2 -second blocks there have been so to make the numbers easier, lets guess at around 300, which makes the odds of a given block being less than 2 seconds around 1 in 1000, or 0.001.
From the statistics on blockchain.info, it looks like there are around 2.5 orphaned blocks per day. The total number of blocks each day is tuned to be 144 (one every ten minutes), so dividing this by 2.5 gives around 60, or a 1 in 60 chance of there being such a collision on a given block.
if my maths is right, this means there is a a 1 in 1000 chance of each participant hitting a 2 second block, so multiply these together to get 1 in 1000000, and there is a 1 in 60 chance of there being a collision in this way, so the odds of this happening would be roughly 1 in sixty million. To put this in perspective, you have a 1 in 600000 chance of being struck by lightning, and this would appear to be some 100 times less likely!

Now, further up there, I made an assumption - that the block difficulty is 'correct'. As I understand it, the block difficulty essentially defines how many leading zeroes must be in a block's hash for it to be considered 'solved'. For example, the last block (found by us!) had a hash of 0000000000000000d69d39dbe4e025909fc30b4be52abfaccfec9315c497ac6c, the digits after the leading zeroes are irrelevant (which is what leads to block collisions in the first place, as two hashes can be found with the same number of leading zeroes).
The block itself is composed of the newly found hash, the hash from the previous block, the block number, difficulty and time, the pool's address, and all the transactions in that block (this is a simplified description), so my question is this - since the odds of two pools finding a 2 second block at the same time is so low (and I stick by 'vanishingly small' as a good description), is it possible that some blocks have more 'solutions' than are statistically expected - in other words, for some blocks, are there more solutions than expected with that number of leading zeroes?
For example, the hash above has 16 leading zeroes, in binary this is 128 leading zeroes, so if my understanding is correct, the odds of getting this out of any random hash would be 2^128.
Any thoughts?
binja9
Newbie
*
Offline Offline

Activity: 27
Merit: 0


View Profile
March 02, 2014, 02:38:14 PM
 #15579

My understanding is that when two pools find the 'same' block, they are actually finding different hashes that meet the difficulty requirement (please correct me if I am wrong). In this case, given that the network difficulty makes this so that the expected block length is ten minutes, and invalid blocks are not that common (IIRC, we have seen two in the last month or so), I am quite surprised that there should be such a 'collision' on a two-second block - surely the odds of this happening would be vanishingly small, unless there is something intrinsic that makes the difficulty on certain blocks much lower than it should be.

Not only different hashes; each pool assembles its own block from the available transactions in the transaction pool according to its rules. So the "same" block can potentially differ between the two pools in the sense it contains different transactions.

The last idea is quite interesting. Can someone have enough will and power to check it? :-)
[edit] I'd sure not say vanishingly, but the chance is of course smaller for two pools at once than it is for one pool.

I would have thought that the probability of two people finding a sub 2-second block, at the same time would be the probability of one finding it, squared.
Assuming the block difficulty is correct, at the moment, we are on block 288579. 
I don't know how many 2 -second blocks there have been so to make the numbers easier, lets guess at around 300, which makes the odds of a given block being less than 2 seconds around 1 in 1000, or 0.001.
From the statistics on blockchain.info, it looks like there are around 2.5 orphaned blocks per day. The total number of blocks each day is tuned to be 144 (one every ten minutes), so dividing this by 2.5 gives around 60, or a 1 in 60 chance of there being such a collision on a given block.
if my maths is right, this means there is a a 1 in 1000 chance of each participant hitting a 2 second block, so multiply these together to get 1 in 1000000, and there is a 1 in 60 chance of there being a collision in this way, so the odds of this happening would be roughly 1 in sixty million. To put this in perspective, you have a 1 in 600000 chance of being struck by lightning, and this would appear to be some 100 times less likely!

Now, further up there, I made an assumption - that the block difficulty is 'correct'. As I understand it, the block difficulty essentially defines how many leading zeroes must be in a block's hash for it to be considered 'solved'. For example, the last block (found by us!) had a hash of 0000000000000000d69d39dbe4e025909fc30b4be52abfaccfec9315c497ac6c, the digits after the leading zeroes are irrelevant (which is what leads to block collisions in the first place, as two hashes can be found with the same number of leading zeroes).
The block itself is composed of the newly found hash, the hash from the previous block, the block number, difficulty and time, the pool's address, and all the transactions in that block (this is a simplified description), so my question is this - since the odds of two pools finding a 2 second block at the same time is so low (and I stick by 'vanishingly small' as a good description), is it possible that some blocks have more 'solutions' than are statistically expected - in other words, for some blocks, are there more solutions than expected with that number of leading zeroes?
For example, the hash above has 16 leading zeroes, in binary this is 128 leading zeroes, so if my understanding is correct, the odds of getting this out of any random hash would be 2^128.
Any thoughts?


Thanks for that - good explanation with solid math.
My following query would be - if 2 blocks are found "at the same time" - how is the block owner\solver determined?
If its exact time as suggested earlier then why would 2 miners think they had solved it ?
Sir Alan
Full Member
***
Offline Offline

Activity: 221
Merit: 100


View Profile
March 02, 2014, 04:11:54 PM
 #15580

Thanks for that - good explanation with solid math.
My following query would be - if 2 blocks are found "at the same time" - how is the block owner\solver determined?
If its exact time as suggested earlier then why would 2 miners think they had solved it ?
If you look at a blockchain record, you will see that there are two time stamps: the time the block was found, as recorded by the finder, and the time it was reported to the blockchain, which is the one that counts (but see the next paragraph).  When a block is solved by two miners almost simultaneously, it can (and does) happen that the first finder loses out through being too slow in reporting their success, which may be caused by their own internal issues or by a delay in the internet.  It appears to happen to most pools sooner or later.  Since everybody will continue to work on a block until the new find has been logged and propagated across the network, occasional duplicates are inevitable.

There is a rare complication: if the miner who loses the race happens to solve and report a second block before the first result has been propagated, his blocks will form the new chain by having the longer fork, and the poor sod who got there first loses out.  This could happen by accident; if intentional - which is theoretically possible - it's called "selfish mining".

1Eeyore17YeHrbJW5Q3pSdV8sXujkdrrFc
Pages: « 1 ... 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 [779] 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 ... 1154 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!