Quote from: EdB666 on March 02, 2014, 11:24:05 AM

Quote from: gourmet on March 02, 2014, 06:12:19 AM

Quote from: EdB666 on March 02, 2014, 12:16:50 AM

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.