Quote from: Graet on June 23, 2012, 12:24:37 AM

Quote from: jetmine on June 23, 2012, 12:11:06 AM

Quote from: Luke-Jr on June 22, 2012, 08:28:09 PM

On the other hand, using the lower hash opens the door to new attacks: if I find a block with a super-low hash, I can just wait to broadcast it until someone else finds it with a higher hash, and instant-orphan them!

If you find a block with a super-low hash, you can just broadcast it right away and you GET THE REWARD. There is no incentive to hold the block back, and play chances. The chances would be to have to compete against a later block, which could turn out to be an even lower hash. You can calculate those chances (based on difficulty and your super-low hash), but they never turn out favorably against the guaranteed reward.

Also, how do you know that similar schemes are not already active? I assume your pool doesnt do it, based on what you write in the post I am replying to. But there is plenty of evidence that blocks are not just elected by arrival time (standard client). The two blocks mentioned here in this thread can serve as example. Blockchain.info RX timestamps were half an hour apart, yet based on same clock source. There was no 3rd block at this height, so we can safely assume that Deepbit has either not known, or voluntarily ignored the new block for half an hour. Do you really think that network propagation has caused this phenomena? Or rather it suggests that Deepbit used a different election criteria than arrival time ...

Think about it.

EDIT: The block in question is 183255. If you look at the preceding block 183254, you will notice that blockchain.info tags it as Deepbit too. The same goes for the superceding block 183256. We are looking at a chain of blocks from Deepbit, with a silenced attempt of interruption by someone else. But Deepbit "pokered" during half an hour, and eventually killed the competitor. What was the algorithm used? It isnt the standard client, so tell me.

If only blockchain.info reported block finders correctly. it hasn't for a long time. and is a well known issue.
lots of conspiracy theories come from it
carry on

Timestamps aren't accurate either.

I've thought about it, jetmine, and I simply cannot see any way that a pool can convince a majority of nodes to accept the block it has produced over someone else's. That would require network coercion on a massive scale.

A chain of blocks from deepbit isn't surpising. Deepbit has about 28% of the network hash rate. They will on average solve 28% of the blocks. Each block solved has a 28% chance of coming from them.

This tends to be more accurate with regards to block ownership: http://blockorigin.pfoe.be/blocklist.php