Post
Topic
Board Pools
Re: Plea for smaller hash resolution protocol, with N seconds time window
by
jetmine
on 23/06/2012, 00:11:06 UTC
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.