Bitcoin Forum
September 30, 2016, 11:49:42 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 3152 (80.4%)
Bank transfer / USD - 407 (10.4%)
Gold/silver coins and bars - 359 (9.2%)
Total Voters: 3916

Pages: « 1 ... 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 830 831 832 ... 1104 »
  Print  
Author Topic: [40+ PH] SlushPool (slushpool.com); World's First Mining Pool  (Read 3859030 times)
EdB666
Newbie
*
Offline Offline

Activity: 25


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

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?

1Q2Wsn4wrmg7gzSWVqDZAfWa441khqnCav
1475279382
Hero Member
*
Offline Offline

Posts: 1475279382

View Profile Personal Message (Offline)

Ignore
1475279382
Reply with quote  #2

1475279382
Report to moderator
1475279382
Hero Member
*
Offline Offline

Posts: 1475279382

View Profile Personal Message (Offline)

Ignore
1475279382
Reply with quote  #2

1475279382
Report to moderator
1475279382
Hero Member
*
Offline Offline

Posts: 1475279382

View Profile Personal Message (Offline)

Ignore
1475279382
Reply with quote  #2

1475279382
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1475279382
Hero Member
*
Offline Offline

Posts: 1475279382

View Profile Personal Message (Offline)

Ignore
1475279382
Reply with quote  #2

1475279382
Report to moderator
nottm28
Hero Member
*****
Offline Offline

Activity: 574



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

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: 25


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

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.

1Q2Wsn4wrmg7gzSWVqDZAfWa441khqnCav
J_Dubbs
Full Member
***
Offline Offline

Activity: 238


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

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?

"a bird in the hand is worth two in the bush"
Learn something new?: 1hzpjSkWaxm7XaEMi5P2fL6hhxuj8gxyX
gourmet
Sr. Member
****
Offline Offline

Activity: 311


View Profile
March 02, 2014, 06:12:19 AM
 #15625

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: 25


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

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?

1Q2Wsn4wrmg7gzSWVqDZAfWa441khqnCav
binja9
Newbie
*
Offline Offline

Activity: 27


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

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


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

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
binja9
Newbie
*
Offline Offline

Activity: 27


View Profile
March 02, 2014, 04:31:48 PM
 #15629

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

Brilliant - thanks for the clear explanation
gourmet
Sr. Member
****
Offline Offline

Activity: 311


View Profile
March 02, 2014, 05:35:46 PM
 #15630

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?

By extremely short blocks, you can't account for mean orphan probability. By a two-second block, probability of orphan race is extremely high, near to 100% IMHO, as the time differences between the good and the orphaned block normally are of the same size as is the block duration by a 2-second block. So I think you must leave out your "60" multiplier.
nottm28
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 02, 2014, 07:05:52 PM
 #15631

Enter Organofcorti please to clear this up...

donations not accepted
EdB666
Newbie
*
Offline Offline

Activity: 25


View Profile
March 02, 2014, 07:21:47 PM
 #15632


By extremely short blocks, you can't account for mean orphan probability. By a two-second block, probability of orphan race is extremely high, near to 100% IMHO, as the time differences between the good and the orphaned block normally are of the same size as is the block duration by a 2-second block. So I think you must leave out your "60" multiplier.

Good point - the odds still work out at around 1 in 1000000, but as Terry Pratchett once wrote, million-to-one chances happen nine times out of ten. Smiley

I still wonder if the contents of some blocks can make the difficulty vary significantly from the assigned difficulty though. Perhaps there is a weakness in (double) SHA256 where hash collisions are more likely with certain values?
Maybe OrganOfCorti can help us out on this one? Any crypto experts around? Where's Bruce Sterling when you need him...

1Q2Wsn4wrmg7gzSWVqDZAfWa441khqnCav
Trefdraeth
Jr. Member
*
Offline Offline

Activity: 32


View Profile WWW
March 02, 2014, 09:15:15 PM
 #15633


By extremely short blocks, you can't account for mean orphan probability. By a two-second block, probability of orphan race is extremely high, near to 100% IMHO, as the time differences between the good and the orphaned block normally are of the same size as is the block duration by a 2-second block. So I think you must leave out your "60" multiplier.

Good point - the odds still work out at around 1 in 1000000, but as Terry Pratchett once wrote, million-to-one chances happen nine times out of ten. Smiley

I still wonder if the contents of some blocks can make the difficulty vary significantly from the assigned difficulty though. Perhaps there is a weakness in (double) SHA256 where hash collisions are more likely with certain values?
Maybe OrganOfCorti can help us out on this one? Any crypto experts around? Where's Bruce Sterling when you need him...

OOC is the man, he will elucidate....
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1890


Poor impulse control.


View Profile WWW
March 02, 2014, 10:51:59 PM
 #15634


By extremely short blocks, you can't account for mean orphan probability. By a two-second block, probability of orphan race is extremely high, near to 100% IMHO, as the time differences between the good and the orphaned block normally are of the same size as is the block duration by a 2-second block. So I think you must leave out your "60" multiplier.

Good point - the odds still work out at around 1 in 1000000, but as Terry Pratchett once wrote, million-to-one chances happen nine times out of ten. Smiley

I still wonder if the contents of some blocks can make the difficulty vary significantly from the assigned difficulty though. Perhaps there is a weakness in (double) SHA256 where hash collisions are more likely with certain values?
Maybe OrganOfCorti can help us out on this one? Any crypto experts around? Where's Bruce Sterling when you need him...

OOC is the man, he will elucidate....

Thanks for the vote of confidence guys, but I'm having trouble following the question and answers. Can someone boil post a precis of the question?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
nottm28
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 02, 2014, 11:29:49 PM
 #15635

Thanks for the vote of confidence guys, but I'm having trouble following the question and answers. Can someone boil post a precis of the question?

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 the question is "are the odds of two pools finding a 2 second block at the same time 'vanishingly small' ?"...

donations not accepted
gourmet
Sr. Member
****
Offline Offline

Activity: 311


View Profile
March 02, 2014, 11:44:48 PM
 #15636


By extremely short blocks, you can't account for mean orphan probability. By a two-second block, probability of orphan race is extremely high, near to 100% IMHO, as the time differences between the good and the orphaned block normally are of the same size as is the block duration by a 2-second block. So I think you must leave out your "60" multiplier.

Good point - the odds still work out at around 1 in 1000000, but as Terry Pratchett once wrote, million-to-one chances happen nine times out of ten. Smiley

I still wonder if the contents of some blocks can make the difficulty vary significantly from the assigned difficulty though. Perhaps there is a weakness in (double) SHA256 where hash collisions are more likely with certain values?
Maybe OrganOfCorti can help us out on this one? Any crypto experts around? Where's Bruce Sterling when you need him...

OOC is the man, he will elucidate....

Thanks for the vote of confidence guys, but I'm having trouble following the question and answers. Can someone boil post a precis of the question?

EdB666 tried to calculate the chance of invalid block (orphan race) by a two-second block.
He started with the chance of two pools finding a two-second block at once, being the chance of one pool finding a two-second block (1/1000) squared, i.e. 1/1000000. For the purpose of finding the chance to one being an orphan, he multiplied this number by the chance for any block to be orphan, which he found to be ~1/60.
I disputed that the last step couldn't be applied for extremely short blocks, as there the chance for orphan is much greater, near to 1, as the block duration approaches the usual time difference between orphan and regular blocks.
EdB666
Newbie
*
Offline Offline

Activity: 25


View Profile
March 02, 2014, 11:45:27 PM
 #15637

Thanks for the vote of confidence guys, but I'm having trouble following the question and answers. Can someone boil post a precis of the question?

In short:

I noted that we had a 35 second block and suggested that this might be some sort of record - another poster mentioned that we once had a 2 second block, but it was invalid.
This got me thinking that this situation must be extremely unlikely to happen, since the odds of a block lasting 2 seconds are quite short, and the odds of two pools finding a two second block at the same time would be even shorter. A quick estimate of the odds, if my understanding of the maths is right, is that the probability of a block being 2 seconds or less is around 0.001, so two at the same time would be around 0.000001, or 1 in 1 million (as pointed out by another poster, the odds of there being a 'race' between these two would be close to one because the block time is so short, rather than 1 in 60, which seems to be the approximate rate of orphaned blocks in the network)
This led me to wonder whether there is something about the (double) SHA256 algorithm that might lead to hash collisions being more likely for certain blocks, so that these blocks rather than being expected to last on average 10 minutes, would have much lower than expected difficulty. This might shorten the odds of there being an orphaned 2 second block. I don't know how possible this actually is, given that the block contains the address of the pool doing the hashing, so that the actual block being computed by two pools would differ.
So, I suppose what I am asking is whether my estimates seem fair, or if I have got the maths all wrong, and whether it is plausible that the hashing algorithm could lead to collisions in this way, causing the occasional block to be much easier to solve, for certain pools, or the network as a whole. I appreciate that cryptanalysis is far from a simple topic, so the second question is really more rhetorical.

1Q2Wsn4wrmg7gzSWVqDZAfWa441khqnCav
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1890


Poor impulse control.


View Profile WWW
March 03, 2014, 01:54:31 AM
 #15638

Before I get started, was the 2 second block invalid because it lost an orphan race or because it was invalid for some other reason? And was it two seconds after the last solved block for the network or for the pool?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
gourmet
Sr. Member
****
Offline Offline

Activity: 311


View Profile
March 03, 2014, 05:23:07 AM
 #15639

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

Blockchain.info says it's main chain...?
Acording to the link, it's ours, and there's no other block at that height.
wdalessi
Newbie
*
Offline Offline

Activity: 14


View Profile
March 03, 2014, 08:20:32 AM
 #15640

I am curious what effect it could or would have to start mining in a pool after it shows a luck rating of below 80% long term (Monthly), and 60% short term (1 week).

I know this method is used extensively in stock trades. They call it the RSI or Relative Strength Index.

http://www.investopedia.com/terms/r/rsi.asp

Time and price movements are not random, as say hashing is. Luck can be relative, just as Relative Strength is.

Though it is possible to have permanently bad or low luck, it can not happen in nature over extremely long periods of times.

Yes you can flip "Heads" on a coin 100 times in a row, but if starting at toss #1 the laws of probability will prove out in the long run. Aberrations are just "Variance" of the longer term averages.

This can be used to a miners advantage.

If you only start mining on a pool when it has short term (1 to 2 Weeks) luck below  say 60 and switch to Pay Per Share when the pool luck goes above say 120, how would this affect the long term earnings of a miner?

Because just as Bad Luck, never lasts, so to Good Luck can also not last.

Unfortunately my college math skills have long been forgotten.
Pages: « 1 ... 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 830 831 832 ... 1104 »
  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!